Medical device metadata

ABSTRACT

Methods and systems of patient treatment are disclosed. The methods and systems include use of medical device informatics to modify and validate therapies and drugs used in those therapies. In certain embodiments, a medical device, such as a medical infusion pump, interfaces with a server to administer the patient treatments. In one such embodiment, a method for use of metadata on medical devices is disclosed. A method includes associating metadata with one or more medical devices, the metadata corresponding to an attribute of the medical devices. The method also includes storing the metadata on a server, the server configured to communicate with each of the medical devices by using the metadata.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to U.S. Provisional PatentApplication No. 60/964,444, entitled “Patient Treatment SystemsEmploying Medical Device Informatics”, and filed Aug. 10, 2007. Thatapplication is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

In general, the present disclosure relates to treatment of patients viasystems for use and control of medical devices. More specifically, thepresent disclosure relates to software for treatment of patients usingmedical devices.

BACKGROUND

Patients at hospitals and other care centers require controlled therapyadministration and monitoring. Hospitals and care centers use a varietyof types and brands of medical devices to assist in monitoring andtherapy administration. For example, medical devices used to assist intherapy administration may include medical infusion pumps, pulseoximeters, cardiopulmonary monitors, and other therapy delivery andpatient monitoring equipment. The various types and brands of medicaldevices each generally use differing, proprietary communicationstandards.

The proprietary standards employed by the different devices limitinteroperability among the devices, making therapy administrationdifficult. During use of one or more of the medical devices, a caregivermay want to perform a number of actions related to the medical device.For example, a caregiver may wish to set parameters in a medical devicebased on the observed characteristics of the patient. Or, the caregivermay wish to view data gathered by a monitor. Due to the proprietarystandards used by various medical devices, the caregiver may use anumber of types of software and hardware to access the informationgathered by the medical device needed to treat the patient.

Coordinating usage of medical devices also can be difficult. A singlemedical device can be programmed for administering different therapiesand in different locations within a hospital. Usage records of multiplemedical devices of varying types and in different hospitals may need tobe compared. Similarly, the status of a medical device can be difficultto monitor because the devices are often in locations other than wherethe caregiver is located.

SUMMARY

Methods and systems of patient treatment are disclosed. The methods andsystems include use of medical device informatics to modify and validatetherapies and drugs used in those therapies. In the various aspects ofthe present disclosure, a medical device, such as a medical infusionpump, interfaces with a server to administer treatments to patients.

In certain aspects, medical device metadata is used to define a medicaldevice within a medical device network. In further aspects, messages arecommunicated between a medical device and server to define treatmentsand other operations to the medical device. In still other aspects,operational and historical data is communicated from medical devices toa medical device server to allow remote monitoring of the administrationof a therapy to a patient. In further aspects, timing parameters dictatecommunication and tracking of events between a medical device and amedical device server.

In a particular aspect, a method of communication between a medicaldevice and a server is disclosed. The method includes associatingmetadata with one or more medical devices, the metadata corresponding toan attribute of the medical devices. The method also includes storingthe metadata on a server, the server configured to communicate with eachof the medical devices by using the metadata.

In a second aspect, a system for communicating with a plurality ofmedical devices is disclosed. The system includes a plurality of medicaldevices and a server communicatively connected to the plurality ofmedical devices. The server includes a memory configured to storemetadata describing the medical devices and a programmable circuitoperatively connected to the memory. The programmable circuit isconfigured to execute program instructions to associate metadata withone or more medical devices, the metadata corresponding to at least oneattribute of the medical devices. The programmable circuit is alsoconfigured to execute program instructions to store the metadata on aserver and communicate information including the metadata with at leastone of the medical devices.

In a third aspect, a method of communication between a medical deviceand a server is disclosed. The method includes associating metadata witheach of a plurality of medical devices, the metadata corresponding to atleast one attribute common to the medical devices. The method alsoincludes associating second metadata with at least one medical device ofthe plurality of medical devices, the second metadata corresponding toat least one custom attribute of the medical device. The method furtherincludes storing the metadata on a server, the server configured tocommunicate with each of the medical devices by using the metadata. Themethod also includes selecting a medical device and communicatinginformation including the metadata with the medical device.

In a fourth aspect, a method of communication between a pluralitymedical devices and a server is disclosed. The method includesgenerating a message to a medical device server at a medical device, themessage including metadata used to identify the medical device. Themethod further includes receiving a message from the medical deviceserver at the medical device, the message including metadata identifyingthe medical device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary medical device network in which aspects of thepresent disclosure may be implemented;

FIG. 2 is a block diagram of a medical device useable in aspects of thepresent disclosure;

FIG. 3 is a diagram of a software architecture for a medical devicenetwork;

FIG. 4 is a diagram of a second software architecture for a medicaldevice network;

FIG. 5 is a flowchart of methods and systems for remote management ofmedical devices controlled by multiple entities;

FIG. 6 is a flowchart of methods and systems for server based control ofmedical devices;

FIG. 7 is a state diagram of possible state for remote control of amedical device;

FIG. 8 is a functional diagram of a messaging system for use in amedical device network;

FIG. 9 is a flowchart of methods and systems for communication between amedical device and a medical device server;

FIG. 10 is a flowchart of further methods and systems for communicationbetween a medical device and a medical device server;

FIG. 11-16 are data models including metadata useable to facilitateextensible communication systems for medical devices and medical deviceservers;

FIG. 17 is a flowchart of methods and systems for filtering medicaldevice events;

FIG. 18 is a flowchart of methods and systems for managing maintenanceof medical devices;

FIGS. 19-24 are data models including event metadata useable to trackevents occurring in medical devices;

FIG. 25 is a diagram of a data packet formatted for transmission from amedical device server to one or more medical devices;

FIG. 26 is a flowchart of methods and systems for delivery of the datapacket of FIG. 25;

FIGS. 27-32 are data models including metadata useable to facilitatedelivery of data packets to medical devices from a medical deviceserver;

FIG. 33 is a schematic diagram including metadata useable to synchronizetime within a medical device network;

FIG. 34 is a flowchart of methods and systems for synchronization ofmedical devices in a medical device network;

FIG. 35 is a flowchart of methods and systems for time adjustment ofevent log data;

FIG. 36 is a block diagram of functional units of a medical deviceserver, according to a possible embodiment of the present disclosure;

FIG. 37 is a block diagram of medical device server administrationsystems;

FIG. 38 is a sample medical device administration event tracking reportaccessible from a medical device server;

FIG. 39 is a sample security event tracking report accessible from amedical device server;

FIG. 40 is a sample security event trending report accessible from amedical device server;

FIG. 41 is a sample user history report accessible from a medical deviceserver;

FIG. 42 is a user interface for management of medical device metadata;

FIG. 43 is a further user interface for installation of medical devicemetadata;

FIG. 44 is a user interface for management of data packet distributionin a medical device network;

FIG. 45 is a further user interface for deployment of data packets tomedical devices in a medical device network;

FIG. 46 is a user interface confirming deployment of a data packet to amedical device;

FIG. 47 is a sample quarantine report indicating erroneous datatransmission from a medical device server to a medical device;

FIG. 48 is a sample detailed quarantine report, corresponding to thequarantine report of FIG. 47;

FIG. 49 is a sample package deployment report displaying deployments ofdata packets from a medical device server to medical devices;

FIG. 50 is a sample package deployment error report displaying erroneousdeployments of data packets from a medical device server to medicaldevices;

FIG. 51 is a sample maintenance report displaying medical devicemaintenance events;

FIG. 52 is a sample medical device fault report displaying medicaldevice faults communicated to a medical device server;

FIG. 53 is a sample medical device fault trending report displayingtrends in medical device faults communicated to a medical device server;

FIG. 54 is a flowchart of methods and systems for communicatingparameter changes from a medical device server to a medical device;

FIG. 55 is a schematic diagram including metadata useable to facilitatetherapy-based programming of medical devices from a medical deviceserver;

FIG. 56 is an exemplary messaging sequence for therapy-based programmingof a medical device;

FIG. 57 is a flowchart of methods and systems for tracking changedmedical device parameters communicated to a medical device server;

FIG. 58 is a sample medical device history report displaying event logdata communicated from a medical device to a medical device server;

FIG. 59 is a sample therapy history report displaying therapy event logdata communicated from a medical device to a medical device server;

FIG. 60 is a sample therapy trending report displaying therapy trendsderived from therapy event log data communicated from a medical deviceto a medical device server;

FIG. 61 is a sample therapy change history report displaying changes totherapies in therapy event log data communicated from a medical deviceto a medical device server;

FIG. 62 is a sample therapy change trending report displaying therapychange trends derived from therapy event log data communicated from amedical device to a medical device server;

FIG. 63 is a flowchart of systems and methods for determining an on-linestatus of a medical device;

FIG. 64 is a flowchart of systems and methods for collecting telemetrydata from a medical device;

FIG. 65 is an exemplary messaging sequence for receiving telemetry datafrom a medical device; and

FIG. 66 is schematic diagram including metadata useable to facilitatecommunication of telemetry data from medical devices to a medical deviceserver.

DETAILED DESCRIPTION

Various embodiments of the present invention will be described in detailwith reference to the drawings, wherein like reference numeralsrepresent like parts and assemblies throughout the several views.Reference to various embodiments does not limit the scope of theinvention, which is limited only by the scope of the claims attachedhereto. Additionally, any examples set forth in this specification arenot intended to be limiting and merely set forth some of the manypossible embodiments for the claimed invention.

The logical operations of the various embodiments of the inventiondescribed herein are implemented as: (1) a sequence of computerimplemented steps, operations, or procedures running on a programmablecircuit within a computer, (2) a sequence of computer implemented steps,operations, or procedures running on a programmable circuit within amedical device; and/or (3) interconnected machine modules or programengines within the programmable circuits.

The description set forth herein discusses use and programming of avariety of medical devices and a medical device server in a medicaldevice network. One skilled in the art will realize that a wide varietyof medical devices are used in administering a therapy to a user, suchas medical infusion pumps, pulse oximeters, cardiopulmonary monitors,and other therapy delivery and patient monitoring equipment. These andadditional medical devices may be used in the medical device network ofthe present disclosure. In various aspects of the present disclosure,the term medical device server refers to a computing system and amessage handling and storage service used for coordination of variousother components of the system. Additionally, the term “user” in thecontext of the medical device generally applies to the person who isreceiving a therapy. In many other contexts, such as the context ofusage of the medical device server, the user could also refer to anyother person such as a caregiver that is operating the medical device ora computer with access to information about the medical device.

Additionally, the medical devices and interconnected computing systemsconsidered in the present disclosure generate and present informationand fields in user interfaces and reports, which are also referred to asdisplays. The user interfaces and reports can include fields,alpha/numeric character strings, times, and dates. The fields, alsoreferred to as cells, prompt users to enter and/or select information.Various types of input and display devices are available on variouscomputing systems and medical devices.

The various types of medical devices encompassed by the presentdisclosure execute or utilize operating parameters, which customize orpersonalize operation of computer implemented steps, machine modules,and programs to meet the requirements of individual medical deviceusers. The operating parameters can be numerical values, text strings,flags, argument names, or any other aspect of medical device programmingthat the user or a caregiver can set to control operation of the medicaldevice. In certain aspects of the present disclosure, metadata indicatesa textual definition of the capabilities of the various operatingparameters within the medical device, and to servers and other computingsystems interfaced with the medical device.

I. Hardware Environment

Referring generally to FIGS. 1 and 2, a generalized hardware environmentis described. FIG. 1 shows an exemplary medical device network 100 inwhich aspects of the present disclosure may be implemented. The medicaldevice network 100 provides a method by which a variety of medicaldevices and communication systems intercommunicate. The medical devicenetwork 100 includes a medical device server 102 interconnected with avariety of types of medical devices. The medical devices can include anactive medical device 104, a passive medical device 106, and a pluralityof exemplary medical devices shown to be medical infusion pumps 108.

The active medical device 104 refers to any of a number of medicaldevices configured to assist in administering a therapy to a patient.Active medical devices include medical infusion pumps for delivery offluidic therapies, or other therapy-providing equipment. In oneembodiment, the active medical device 104 is a medical infusion device,such as the medical infusion pumps 108 shown.

The passive medical device 106 refers to any of a number of observationdevices configured to monitor the status of a patient, rather than toactively assist in administering a therapy to that patient. Examples ofpassive medical devices include pulse oximeters, cardiopulmonarymonitors, or other patient observation systems for measuring vital signsof the patient, such as breathing, heart rate and rhythm, blood oxygenlevels, and other health indicators.

The medical device server 102 communicates with the medical devices, andis one or more generalized or application-specific computing systems.The medical device server 102 is configured to store and retrieve datareceived from the various medical devices 104, 106, 108. The datareceived by the medical device server 102 can include event log data,programming data, and various other data transmitted to the server 102from the medical devices 104, 106, 108.

Optionally, the medical device network 100 includes additional computingdevices, such as workstations 110 and portable computing systems 112,configured to allow communicative connection to the medical deviceserver 102. The workstations 110 and portable computing systems 112 aregeneralized computing systems or thin client computing systems having acommunication interface allowing access to the medical device server.The workstations 110 and portable computing systems 112 generallyinclude input devices and displays, so as to allow a user (i.e. acaregiver) access to data about a patient when that user is not in thesame location as the patient. The users may access the medical deviceserver 102 via the workstation 110 or portable computing system 112 toretrieve data gathered from a medical device, and may instruct themedical device server 102 to communicate various messages or softwarepackages to one or more of the medical devices.

The medical device network 100 optionally includes networkinfrastructure components, such as a switch 114 and a wireless accesspoint 116. The network infrastructure components are configured toprovide the communication infrastructure between the various medicaldevices 104, 106, 108, the medical device server 102, and any additionalcomputing systems 110, 112. Although the medical device network 100requires a communicative conduit between the various components includedin the network, the specific components included in a given medicaldevice network will vary based upon the particular infrastructure andneeds of users of the medical device network. Therefore, the switch 114and wireless access point 116 are intended as exemplary components forimplementation of a communicative interconnection between the variouscomponents of the network. Additional types of medical devices,computing systems, or networking components may be used in the network100 as well.

FIG. 2 shows an exemplary block diagram of a medical device 200. Themedical device 200 is any of a number of types of active or passivemedical devices for therapy administration or monitoring of a patient.In one possible embodiment, the medical device 200 is a medical infusionpump configured to infuse drugs and other fluidic therapies to apatient. Other types of medical devices are possible as well.

The medical device 200 includes a programmable circuit 202 interfaced toa memory subsystem, including, for example, Random Access Memory (RAM)204, a flash memory 206, and an electrically erasable, programmablememory (EEPROM) 208. The RAM 204 stores operational parameters of themedical device, as well as any non-critical storage with respect tooperational data or instructions. The flash memory 206 storesinstruction and/or data memory defining operation of the pump, such aspump programs, pump parameters for use in those pump programs, or othersystem firmware. The EEPROM 208 stores a set of initial instructionsthat are used by the medical device 200 and must be preserved in theevent of a failure of the device, such as due to a power failure, deadbattery, or other unanticipated event. The EEPROM 208 optionallyincludes firmware or instructions which may be read or copied into theRAM 204 or flash memory 206 for execution, as necessary.

In various embodiments of the medical device 200, the various componentsof the memory subsystem used are dictated by the needs of the medicaldevice. In certain devices, one or more of the memory system componentsdescribed herein are not present. In such devices, some or all of thedata and instructions stored in that device may be stored in anothercomponent of the memory subsystem present in the device. RAM may alsotemporarily provide storage for critical operational data orinstructions. Also, alternate embodiments can be provided whereby thecontents of the flash memory and the contents of the EEPROM memorypreviously described may be interchanged, or whereby the contents may beentirely stored in one type of non-volatile memory and none in theother. Finally, other types of non-volatile memory may be used instead,such as ferro-electric memory or others.

The medical device 200 further includes a battery system 210 configuredto provide a direct current source of power to the medical device whenthe device cannot be plugged in to a wall power outlet or some other ACpower source. In one embodiment, the battery system 210 includes arechargeable lithium-ion smart battery system configured to providepower management and intelligent switching between DC and AC power modesdepending on the presence of AC power. In further embodiments, thebattery system 210 includes different types of battery systems, such asa rechargeable battery system including a nickel-cadmium battery.

The medical device 200 includes an input device 212 and an output device214 interfaced to the programmable circuit 202. The input device 212allows a user at the location of the medical device to adjust theactivity of the device. The input device 212 can be, for example, amouse, keyboard, keypad, trackball, touch screen, control buttons, orother user-controllable devices. The output device 214 can be any typeof audio, video, or data interface configured to provide informationregarding the medical device to users and devices external to thedevice. In various embodiments, the output device 214 may be a datainterface to a second medical device, or may be a connection to anexternal monitor for display of information to a user regarding thestatus of the medical device 200.

The medical device 200 also includes a display device 216 and an alarm218. The display device 216 is a visual device capable of displayinginformation to a user of the device. In various embodiments of themedical device 200, the display device 216 can be, for example, adisplay device, such as an LCD, CRT, or other screen. Additional typesof display devices are possible as well. Furthermore, although themedical device is shown as including a display device 216, in alternateembodiments a display device is not required. The alarm 218 can beconfigured to provide various types of audio indications to the user ofvarious conditions detected in the user or the device. These conditionsinclude a health condition detected, such as an abnormally low or highheart rate or respiration rate, or a warning related to the device, suchas indicating that a supply of a drug is running low, or thatmaintenance may be required for the device. The alarm optionallytriggers based on additional alarm conditions beyond those listed here;the alarms selected generally relate to the type of medical deviceimplemented and conditions experienced by that device.

A wired communication interface 220 provides a data communicationconnection from the medical device 200 that interfaces with a medicaldevice server or other generalized computing system. The wiredcommunication interface 220 interfaces to the programmable circuit 202,and sends and receives data from the medical device 200. In variousembodiments, the wired communication interface 220 can be an Ethernet orother data connection capable of communicating and receiving digitaldata.

A wireless communication interface 222 provides an alternativecommunication interface to the wired communication interface 220, suchthat the medical device 200 can maintain data communications with amedical device server or other computing system when a wiredcommunication connection is not available or convenient, based on thelocation of the medical device. The wireless communication interface 222interfaces to the programmable circuit 202, and sends and receives datawirelessly from the medical device. Usage of one or both of the wired orwireless communication interfaces is dependent upon the location of themedical device and the need for communication with a medical deviceserver. In one embodiment, the medical device provides a constant datastream to one or both interfaces such that individuals with access to amedical device server can continuously track the status of the medicaldevice. In further embodiments, the medical device activates and/orcommunicates using one or both interfaces periodically, orintermittently, so as to update the operational data or otherinformation held by either the medical device or the medical deviceserver.

The medical device 200 also includes a patient interface 224. Thepatient interface 224 controls the mechanical component of the medicaldevice 200 which monitors or delivers a therapy to the user. The patientinterface 224 varies among the different types of medical devices basedupon the function of the device. In the case where the medical device200 is a monitor, the patient interface 224 may include a sensor orother physical detection equipment. In the case where the medical device200 is a medical infusion pump, the patient interface may include adrive mechanism, occlusion sensor, fluid volume sensor, or other drugcontrol or delivery interfaces. Other medical devices, and correspondingpatient interfaces, are possible as well. Additional components beyondthose shown may also be included in various embodiments of the medicaldevice 200, depending upon the particular application to which thedevice is directed.

II. Overall Software Environment

FIGS. 3-6 show an overall software environment for the medical devicenetwork 100 and its components, according to various embodiments of thepresent disclosure. The software environment disclosed herein isdiscussed in two sections: (1) those aspects which relate tocommunications between medical devices and a medical device server,found in part III, and (2) aspects encompassing user interaction withthe medical device network, such as to view data related to medicaldevice activity, or to administer changes or additions to the medicaldevice network, found in part IV. Both aspects relate generally tocoordination of medical devices in a medical device network, of whichthe primary physical features are described above in FIGS. 1-2.

The various software disclosed herein, including the metadatainstallation software, package deployment software, and server softwaredescribed in Parts II-IV, below can be packaged in a variety of ways,and organized for a variety of different medical device networks. In apossible embodiment, the various software aspects are included in asoftware development kit (SDK) including some or all of the varioussoftware components described herein. In such an embodiment, the medicaldevices can include monitors and medical infusion pumps, and thesoftware can include pre-packaged metadata files useable on both themedical devices and medical device server. User-readable documentationregarding the software can be included as well.

Additionally, the various software disclosed herein and claimed belowcan be embodied on any of a number of types of computing systemsoperable within the hardware environment of FIGS. 1-2. For example, acomputing device typically includes at least some form ofcomputer-readable media. Computer readable media can be any availablemedia that can be accessed by the computing system. By way of example,and not limitation, computer-readable media might comprise computerstorage media and communication media.

Computer storage media includes volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer readable instructions, data structures,program modules or other data. Computer storage media includes, but isnot limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium that can be used tostore the desired information and that can be accessed by a computingsystem.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism and includesany information delivery media. The term “modulated data signal” refersto a signal that has one or more of its characteristics set or changedin such a manner as to encode information in the signal. By way ofexample, and not limitation, communication media includes wired mediasuch as a wired network or direct-wired connection, and wireless mediasuch as acoustic, RF, infrared, and other wireless media. Combinationsof any of the above should also be included within the scope ofcomputer-readable media. Computer-readable media may also be referred toas computer program product.

FIG. 3 shows a software architecture 300 in which aspects of the presentdisclosure are implemented. The software architecture 300 provides anoperating environment in which medical device data can be stored andmanaged remotely from the medical devices. The software architecture 300also provides an extensible architecture in which a variety of types ofmedical devices can operate. The software architecture 300 operatesusing one or more computing systems in communicative connection tovarious medical devices, and is configurable to operate across multiplelocations and different business entities. The software architecture 300operates within a medical device network including one or more medicaldevices and a medical device server. A possible configuration of themedical device network in which the software architecture operates isdescribed above in FIG. 1.

In one embodiment, aspects of the software architecture 300 areimplemented using the relational and business intelligence components ofMicrosoft SQL Server 2005, distributed by Microsoft Corporation. In suchan embodiment, various modules, such as web interfaces, may be providedusing a web service, such as Microsoft Internet Information Services(IIS) platform. In further possible embodiments, aspects of the systemare implemented using Microsoft SQL Server 2000, Oracle, or otherdatabase management and business intelligence products, in conjunctionwith various web services, such as an Apache-based or other web server.

The software architecture 300 includes one or more medical devices 302,back office components 304, and client applications 306. The medicaldevices 302 monitor or deliver therapies to patients, as directed by acaregiver. The medical devices 302 can be any of a variety ofprogrammable medical devices such as those discussed in conjunction withFIGS. 1-2, above.

The back office components 304 include one or more medical deviceservers 308, an administration module 310, an event tracking module 312,and an operations module 314. The medical device server 308 managescommunication with the various medical devices 302 associated with theback office components 304, such as by relaying messages between thevarious modules 310, 312, 314 and the medical devices 302. The medicaldevice server 302 creates messages understandable to the medical devices302 and the various modules 310, 312, 314 such that a variety of typesof medical devices can be managed using the modules. Using the messagessent to the medical devices 302, the medical device server 308 collectshistorical information from the medical devices, automates variousmaintenance operations, assists with therapy setup at a user's bedside,and provides medical device monitoring. In a possible embodiment, themedical device server 302 manages a metadata-based messaging system forcommunicating with a variety of types of medical devices, such as byusing XML or some other type of metadata or markup language via SOAP oranother messaging protocol.

In one possible embodiment, the medical device server 308 resides on acomputing system which also hosts the additional back office components304. In a further embodiment, the medical device server resides onseparate computing hardware from the other back office components. Insuch systems, the medical device server 308 may be placed at a differentlocation from the other back office components, or may be managed by adifferent entity from the other back office components, as is describedin FIGS. 4-5, below. For simplicity, throughout the description of thesoftware aspects the term medical device server is intended to encompasseither the medical device server 308 or the back office components 304as a whole, depending upon the specific implementation chosen. Incertain embodiments, the medical device server 308 can be placed on oneor more physical computing platforms, resulting in the presence ofmultiple medical device servers.

The administration module 310 provides an interface to administrationdata 316, which the medical device server 308 and client applications306 can request for various reasons, such as to allow access to event oroperational data, described below. The administration data 316 includesuser validation information, such as username, password, IPauthentication, or other user validation, as well as rights informationdefining the access rights associated with the user. For example, theadministration data 316 may associate a username with a password, andrequire a user to provide the correct username and password to receive avalidation right. The username and password information may in turn beassociated with access rights information, which defines the specificcategories of data, subsets of medical devices, or types of commandsallowed to that user. Additional access rights may be defined in theadministration data 316 and managed by the administration module 310 aswell.

The administration data 316 also defines the capabilities of the variousmedical devices 302 managed within the environment 300, by definingoperational parameters by which the medical device server 308 interfaceswith a medical device 302. For example, a medical device configured tomonitor a patient may include a variety of defined parameters relatingto monitoring functions, but will not include parameters relating totherapy delivery. In allowing user-definition of a variety of possiblemedical device capabilities by setting operational parameters within theadministration data, the environment 300 provides a user-extensible setof back office components which are configurable with a variety ofmedical devices having various capabilities, manufactured by differententities, and employed at different locations.

In a particular embodiment, the administration module 310 generates aweb interface accessible to various client application interfaces toremotely validate users or caregivers wishing to access data held withinone or more of the back office components 304. In a further embodiment,the administration module provides an interface allowing remoteapplications to access the data managed by the back office components304.

The event tracking module 312 provides an interface to the medicaldevice server 308, and organizes and manages event data 318. The eventdata 318 corresponds to the historical data regarding various eventsoccurring in the medical devices 302, which are collected and routed bythe medical device server 308. The event data 318 correlates a medicaldevice identifier with an event identifier, and additional descriptiveinformation regarding the event occurring in the medical device.Examples of events tracked using the event tracking module 312 includepower events, alarm events, maintenance events, telemetry events,therapy events, or therapy change events in the various medical devices.Examples of various events and schema used for tracking such events arediscussed below in conjunction with FIGS. 19-24. In a particularembodiment, the event tracking module 312 generates a web interfaceaccessible by the medical device server 308 to transfer data to astorage location of event data 318.

The operations module 314 manages various operational characteristics ofthe system, such as system operational information, therapy orders,maintenance jobs, and other information used to affect operation of thevarious medical devices 302 associated with the environment 300. Theoperations module 314 also provides a web interface to the medicaldevice server 308 for managing the various types of operations data 320,and to various external computing systems to allow those systems to viewthe operations data 320 and transmit commands within the softwarearchitecture 300, such as to the various medical devices 302.

An optional data warehouse 322 aggregates and coordinates the variouspredefined and collected data, including the administration data, theevent data, and the operations data, for use by various clientapplications. In the embodiment shown, a reporting application receivesdata from the data warehouse 322, which aggregates various data from theadministration data 316, the event data 318, and the operations data320. The data warehouse 322 provides a convenient static repositoryuseable to generate reports based on one or more of these types of data.Example reports are described in conjunction with the user to servercommunication systems described in Part IV, below. The data warehouse322 can be formed using any of a number of relational or On-LineAnalytical Processing products, such as SQL Server Analysis Services,Hyperion Essbase, Oracle OLAP, or other data store configured to allowquerying or access to various combinations of data. For thoseembodiments without the optional data warehouse 322, its functionalityas described herein can be provided by the Administration, EventTracking, Operations databases and their corresponding modules, asdescribed herein.

The client applications 306 generally access one or more of the datasources 316, 318, 320, 322 to generate user output forms indicating tocaregivers or other users current or historical information about themedical devices to which that caregiver or user has access. The clientapplications 306 accessing the back end components 304 includeadministration applications 324, reporting applications 326, dashboards328, maintenance forms 330, and various additional external applications332.

The administration applications 324 provide user access to theadministration data 316 include a variety of administration web forms,to define usage rights for other users attempting to access the backoffice components 304, as well as to define the operational parametersof the medical devices 302. Additional administration web forms may beincluded as well.

The reporting applications 326 provide a number of standardized reportsbased on the administration data 316, the event data 318, and theoperation data 320. In an embodiment in which the back office components304 include a data warehouse 322, the reports may be based on theinformation in the data warehouse. Examples of reports built using thevarious types of data tracked in the back office components 304 includesecurity reports, user histories, software deployment reports, medicaldevice programming reports, maintenance reports, device history reports,therapy reports, and other reports. Additional examples of the reportsare described in Part IV, below.

The dashboards 328 allow a caregiver or user to view the status of amedical device 302. The dashboards 328 are based on operation data, andinterface to the operations module 310. The dashboards 328 availablewithin the environment 300 correspond to the various medical devices 302capable of frequently transmitting data to the back office components304. The dashboards 328 receive operational data regarding the medicaldevices, such as the most recent therapy delivered by the devices. Thisinformation is reflected on the dashboard user interface, presented on adisplay device of a computing system accessible to a caregiver or user.In one possible embodiment, the dashboards 328 replicate the visualinterface of the corresponding medical device, but in a web-portalformat.

The maintenance forms 330 display maintenance information to a caregiveror other user of the medical devices 302. The maintenance forms 330display tracked maintenance information included in the operations data320, such as performed maintenance, scheduled maintenance, suggestedmaintenance, and maintenance trends. The maintenance forms 330 alsoallow the user to deploy various updates to the medical devices 302,such as firmware updates and other software deployments. In a possibleembodiment, the operations data 320 includes maintenance scheduleinformation accessible by users via the maintenance forms. In such anembodiment, the maintenance forms 330 display a maintenance schedule toa user, including future maintenance required for various medicaldevices 302 as well as historical maintenance events tracked in theoperations data 320.

Various external applications 332 extend the functionality of thesoftware environment 300 by communicating with the operations module314. The external applications 332 include any applications useable toextend the functionality of the software environment 300.

FIG. 4 displays an alternative software infrastructure 400 to the oneshown in FIG. 3, and may be used in the instance in which the storage ofdata from the medical devices is managed by an entity other than thefacility at which the medical devices operate. For example, the medicaldevices 302 and medical device server(s) 308 may reside at one or morehospitals or health care facilities 404, managed by one or morehealthcare entities, such as counties or private entities. However, thestorage of data from those devices may be managed by a health managementorganization or other organization 405 contracting to manage the data ofthe various facilities at an off-site location. That entity can collectinformation from the medical device server 308 also residing at thefacility, which in turn communicates data appropriately to one of theweb-based modules 310, 312, 314 described above. Such an arrangementallows the hospital to aggregate data from its medical devices at amedical device server, but allows a third party to manage the computinginfrastructure and perform the maintenance tasks related to long termstorage, administration, access and/or reporting of the data.

FIG. 5 shows systems and methods for management of a softwareinfrastructure such as the one shown in FIG. 4, in which a third partyhandles the data management tasks related to the data collected frommedical devices located within and controlled by various healthcareorganizations at various locations, or customer sites. Operational flowwithin the system 500 of FIG. 5 commences at a start operation 500,which corresponds to initialization of the system 500, such as byoperation of various medical devices connected to a medical deviceserver.

A data receipt module 504 receives data generated by the medical devicesmanaged by one or more entities, such as hospitals, clinics, or otherhealth management organizations. In one embodiment, the data receiptmodule 504 corresponds to receipt of various administrative data, eventdata, or operations data from a medical device server or clientapplications, as shown in the back office components 304 of FIG. 4.

An association module 506 associates the data received in the datareceipt module 504 with the medical devices from which the data isreceived. In one possible embodiment, the association module 506associates the data with the various locations at which the medicaldevices reside, or with the various entities controlling the devices, asdefined in the administration data 316. The data association can be alogical or physical relationship between the data, such as can be foundin a file, table, or database.

The association module 506 prepares the data such that when a user froma particular hospital or location seeks information about medicaldevices, the back office components can provide to that user onlyinformation about the medical devices at that same location or withinthe same entity as the user, depending upon the particularimplementation of the association module 506. For example, a singlehospital or ward of a hospital may have a variety of medical deviceswhose data is collected and managed by a third party. A doctor, nurse,or other caregiver working in that hospital or ward may accessinformation related to the specific medical devices in that ward from aremote server, not controlled by that ward or hospital.

An optional program module 508 distributes data or instructions from theback office components to a medical device, based on the specificinstructions related to that entity or location. For example, a hospitalor ward can request a software upgrade to their medical devices, and theback office components will direct the specific software upgraderequested by the hospital to only that entity's devices or devices onlyof a specific type, excluding other devices associated with or monitoredby the back office components.

In a further example, a workstation at a hospital or other healthcarelocation can view status information about the medical devices at thatlocation, such as by execution of the data receipt module 504 and theassociation module 506, above. In this example, the user of theworkstation may optionally choose to reprogram the medical devices, andcan do so by issuing a global command to all of the medical devices of aspecific type at the location associated with the user. The back officecomponents can transmit to the appropriate medical device server thespecific instructions necessary to distribute to the medical devices atthat location, without transmitting those instructions to the samemedical devices at other locations managed by the back officecomponents.

Operational flow terminates at an end operation 510, which correspondsto completion of a communication session with one or more medicaldevices.

FIG. 6 shows systems and method executable within the medical devicenetwork of FIG. 1, in which medical device actions are interconnected.The system 600 specifically relates to interconnection of differenttypes of medical devices at a specific location, such as a group ofmedical devices all associated with a single patient. The system 600includes a number of rules which execute on the medical device server orother back office components so as to determine any additional advisabletherapy or monitoring activity using a second medical device based onobserved activity of a patient with a first medical device, as receivedby the medical device server or back office components.

Operational flow within the system 600 commences at a start operation602, which corresponds to initial monitoring of a patient using aplurality of medical devices connected to a medical device network. Thestart operation 602 also optionally corresponds to receipt of at leastone event at the medical device server, as logged by a first medicaldevice which is associated with a patient.

A status receipt module 604 receives a status of a patient from a firstmedical device used to monitor or administer a therapy to the patient.In one example, the status receipt module 604 can receive a status of apatient from a medical device associated with that patient. The statusof the patient may include the heart or breath rate or regularity, anindication by the patient that he is experiencing pain, the bloodglucose level of the patient, or the progress of one or more therapiesadministered to the patient. The status of the patient optionally alsoincludes alarms generated by medical devices monitoring or deliveringtherapies to the patient.

A determination module 606 executes one or more rules based on thestatus of the patient received from the first medical device. The one ormore rules define whether any additional action is needed with respectto that patient, such as additional or changed therapies or monitoringof the patient. The determination module 606 associates various ruleswith specific medical devices capable of executing the changed therapy.Only those rules are executed which correspond to active medical devicescurrently monitoring or delivering therapies to the patient. In oneexample of execution of the determination module 606, there may exist aninstance in which a monitor senses or is told that the patient isexperiencing pain. In such an instance, one or more rules execute todetermine whether a pain management therapy is available to thatpatient, and, if such a therapy is available, to determine anappropriate therapy to be administered to that patient. For example, ifa medical infusion pump is associated with that patient, thedetermination module 606 concludes that the pump is capable ofdelivering a pain management therapy and calculates appropriate pumpparameters for delivery of the appropriate therapy to the patient.

A program module 608 generates programming for a target medical devicecapable of providing the changed or additional therapy or monitoringdetermined in the determination module 606. The program module 608communicates the changes or additions to the therapy to either aworkstation accessible to a caregiver of the patient, or to a medicaldevice capable of administering the therapy. In one embodiment, theprogram module 608 requests that a caregiver approves the suggestedtherapy determined in the determination module 606. In a furtherembodiment, the program module 608 directly programs the medical devicecapable of delivering the therapy, such that the therapy may bedelivered without any additional caregiver approval or intervention.

Operational flow terminates at an end operation 610. The end operation610 corresponds to the medical device server completing communication ofthe determined therapy to a workstation or medical device.

III. Medical Device to Server Communication

FIGS. 7-35 describe generally various systems and methods forcommunication between the medical devices and the medical device serveror other back office components, as shown in FIGS. 1-2. The systems andmethod described in this section relate to coordination of medicaldevices in a medical device network, which may span across one or morefacilities, organizations, time zones, or other logical entities. Thesesystems can be used during user interaction with the medical devicenetwork, described in Part IV, below, in that involvement with the userrelates to coordination of medical devices as well as collection andcommunication of data from the medical devices in the medical devicenetwork.

Referring now to FIGS. 7-8, communications between a medical deviceserver and a variety of types of medical devices are described. Thecommunication methods used by the medical device server and the medicaldevices provides an extensible system allowing the medical device serverto communicate with a variety of different types of medical devices madeby a variety of different medical device manufacturers, each havingdifferent communication protocols, capabilities, and othercharacteristics.

FIG. 7 shows an exemplary extensible system 700 in which a medicaldevice server associates with a remotely located medical device. Thesystem 700 tracks the states of medical devices associated with amedical device server, and is used to associate new and existing medicaldevices with the medical device server to provide an extensible medicaldevice network allowing intercommunication of a variety of types andbrands of medical devices placed at a variety of different hospitals orlocations within a hospital. In the system 700, every medical devicerecognized by a medical device server will have an associated state heldin a table on the server. Therefore, the system 700 will executeindependently on the server for each medical device associated with theserver. The system 700 commences at a start node 702 corresponding toconnection of the medical device to a medical device network including amedical device server, such as the one shown in FIG. 1.

Upon connection of the medical device, the medical device server mustdetermine whether the medical device is of a known type. If the medicaldevice is of an unknown type, operational flow proceeds to a known state704, which corresponds to receiving information about the capabilitiesof the medical device, so that the medical device is able to be added tothe medical device network. The known state 704 may result fromreceiving user input describing the operational capabilities of themedical device, or may include communication or testing between themedical device and medical device server. When the medical device serverconsiders a device to be in a known state corresponding to the knownstate 704, the medical server treats the medical device as a recognizeddevice, but that is not powered on or otherwise recognized by thesystem. If the medical device is of a known type, operational flowproceeds to a determination node 706, which corresponds to determiningthe state of the medical device.

Four operational states define the operation of the medical device fromthe perspective of the medical device server: a powered state 708, atherapy state 710, a fault state 712, and an alarm state 714. Thepowered state 708 corresponds to a medical device which is powered onand experiencing normal operation, but is not currently being used tomonitor or deliver a therapy to a patient. The powered state 708 isentered from the known state 704 or the determination node 706 when themedical device transmits an indication to the medical device server thatit has been turned on. The powered state is entered from the remainingoperational states, i.e. the therapy state 710, the fault state 712, andthe alarm state 714, when the medical device server receives anindication that the medical device has cleared the condition causing theserver to associate the medical device with one of those states.

The therapy state 710 corresponds to a medical device communicating tothe medical device server that it is currently in operation, deliveringa therapy or monitoring a patient. The specific action taken by themedical device will be dictated by the characteristics of that specificmedical device; however, the medical device server need only recognizethat the medical device is currently in operation. The system 700 canenter the therapy state from any of the other operational states 708,712, 714, or from the determination node 706. When the medical devicesuccessfully completes the therapy, it communicates that event to themedical device server, which returns the table entry associated withthat device to the powered state 708. If the medical device fails tocomplete the therapy due to a fault or alarm event, it will communicatethat event to the medical device server, which changes the table entryassociated with the device to the appropriate operational state.

The fault state 712 corresponds to an error occurring in the medicaldevice, such as a malfunction in the operation of the device duringmonitoring or therapy delivery. The fault state 712 can be entered fromeither the powered state 708 or the therapy state 710, and can also beentered from the determination node 706. In a possible embodiment, thefault state 712 can trigger notification of a caregiver having controlof the medical device that a fault has occurred. In a furtherembodiment, when the medical device server receives an indication whichgenerates a fault state entry in the table, the server can determine thefault occurring in the medical device and can correct the error. Uponclearance of the fault state, the medical device transmits an indicationto the medical device server that it has returned to its previousoperational state, or has entered the powered state 708 if returningfrom the determination node 706. The table held by the medical deviceserver tracking the state of the medical device is updated appropriatelyto reflect the state of the medical device.

The alarm state 714 corresponds to the medical device server receivingan indication from the medical device of an event occurring in themedical device which requires the attention of a doctor, nurse, or othercaregiver. For example, the medical device may be a medical infusionpump which has run out of medicine for delivery. In another example, themedical device is a heart rate monitor, and the event is monitoring anddetection of an abnormally low or high heart rate. The alarm state 714can be entered from either the powered state 708 or the therapy state710, and can also be entered from the determination node 706. Uponclearance of the alarm event, the medical device transmits an indicationto the medical device server that it has returned to its previousoperational state, and the table is updated appropriately.

A nonoperative state 716 may be entered from any of the active states,including the powered state 708, the therapy state 710, the fault state712, or the alarm state 714. The nonoperative state 716 corresponds tothe server being unable to determine if the medical device is active, orwhat state the medical device is in. The nonoperative state 716indicates to a user of the medical device server that attention to thatmedical device may be needed so as to properly associate the medicaldevice to the medical device server.

In an example of operation of the system 700, when a medical device isintroduced into a medical device network, the medical device server mayor may not know how to communicate with it. Assuming it is a knowndevice that is not currently powered, the medical device server willeventually enter the known state 704. When the medical device is turnedon, the medical device will transmit a power on message to the server,which will update the table to indicate that the medical device is inthe powered state 708. The medical device will send to the server amessage when the medical device delivers a therapy, and the medicaldevice server will associate that medical device with the therapy state710. When the medical device completes delivering that therapysuccessfully, the medical device will send a message to the server,which will change the table entry of that device from the therapy state710 to the powered state 708. If the medical device fails for somereason, it will communicate a fault message to the server, which willassociate the medical device with the fault state 712.

If the medical device runs out of a drug or detects a dangerouscondition of the patient, the device will communicate an alarm messageto the server, which will associate the medical device with the alarmstate 714. When the device completes delivering the therapy, it sends amessage to the server that delivery of the therapy is complete, and theserver associates the medical device with the powered state 708. Acaregiver may then turn off the medical device, and prior to shuttingdown the device sends a message to the server, which in turn associatesthe medical device with the known state 704.

FIG. 8 displays a diagram of an exemplary communications system 800incorporating a medical device server and a medical device. Thecommunications system 800 is configured for receipt, processing, andstorage of input messages from external devices, such as medicaldevices. In one embodiment the communications system 800 uses ametadata-based communications protocol, such as the SOAP protocol. Insuch a system, the medical device server uses message schema files tovalidate messages received from medical devices.

The communications system 800 is configured such that messages sent froma medical device 802 are received by a medical device server 804, whichincludes a device server object 806, message handlers 808, and a datatier 810. The medical device 802 can be any of a number of medicaldevices capable of communication with a medical device server. Variousembodiments of the medical device are described above in conjunctionwith FIG. 2.

The medical device server 804 can be any of a number of generalizedcomputing systems configured to collect information from medical devicesand assist with medical device setup and monitoring. The medical deviceserver 804 contains a device server object 806, which handles messagessent and received from the medical device server, and parses themessages to determine that they include required information for themedical device server to act on the message. For example, the deviceserver object can parse various metadata tags contained in the message,as well as data associated with that metadata, to verify the messagetype, source or destination device identification or networkidentification, and message data. Other components of the message may bedetermined as well.

Exemplary message contents describe various features of the deviceserver object 806, as well as for the various device handlersincorporated into the system. A sample device server object definitioncan read as follows:

<Feature> <Id>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</Id><LicenseId>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</LicenseId><Name>Medical Device Secured Server</Name><Provider>MedicalDeviceServer.MedicalDeviceSoapTcpServer,MedicalDeviceServer.MedicalDeviceSoapTcpServer.MedicalDeviceSoapSecureTcpServer</Provider><Description>Receives inbound connection over SSL secured TCP/IPnetworks.</Description> <Type>Server</Type> </Feature>

In this example, the Feature tag defines the object as a feature of thedevice server object. The Id tag defines the GUID, or statisticallyunique number used to identify the feature. The LicenseID tag identifiesthe license containing the features defined. The Name tag provides thename of the feature. The Provider, Description, and Type tags define thevarious implementation details of the object. Additional implementationdetails may be included as well.

One or more message handlers 808 receive the message in its originalformat from the device server object 806, and process the message in amanner to convert the message to a format understandable to and storedby the data tier 810 of the medical device server 804. The varioushandlers are assigned messages based on the type of message received,with each handler processing a specific type of messages in a given way.In one embodiment, the message handlers include an alarm handler, afault handler, a maintenance handler, a power handler, a requesthandler, various telemetry handlers, and various therapy handlers.Additional or fewer handlers are possible, based on the variety of typesof messages managed by the medical device server 804.

A second exemplary server object definition describes various featuresof a message handler 808:

< Feature > <Id>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</Id><LicenseId>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</LicenseId><Name>Medical Device Event Handler</Name><Provider>Informatics.BackOffice.MedicalDeviceServer</Provider><Description>Validates received events and stores them in the Operationsdatabase</Description> <Type>Handler</Type> </Feature>

The example for the message handler 808 is analogous to that describingthe device server object 806, but defined using a Provider tagindicating that the metadata defines a handler configured to define afeature. The message handler 808 can be associated with the deviceserver object 806 using the following code:

<Handler> ... <FeatureId>XXXXXXXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX</FeatureId> <HandlerId>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</HandlerId> ... </Handler>

By tying a feature 806 to a handler 808, the medical device server 804can route specific types of data to the appropriate handler.

A data tier 810 receives messages from the message handlers 808 forstorage, and also responds to requests for data by providing data to therequesting message handler 808 for formation into a SOAP-based messageor transmission to the medical device via the device server object 806.

A. Metadata Programming and Communication

Referring now to FIGS. 9-16, a programming schema is disclosed whichlists metadata used to define the operational characteristics of avariety of medical devices. The metadata also allows the medical deviceserver to communicate with a wide variety of medical devices, such asmedical infusion pumps or other therapy delivery or monitoringequipment. By defining medical devices in the medical device server interms of their operational characteristics rather than specificproprietary interfaces, the medical device server need not understandthe inner workings of each type of medical device. Rather, the serverwill understand how to communicate with the medical device based onexpected operation of that device. In general, the metadata schemadisclosed operates using the XML protocol, and a SOAP based messagingsystem as described above in FIG. 8. However, other standardizedcommunication methodologies could be used as well.

FIG. 9 shows systems and methods for communication between a medicaldevice and a medical device server. The system 900 shown is configuredto provide extensibility to a variety of types and brands of medicaldevices, as described above in FIG. 2. The medical device server cancommunicate with the medical device by defining a predetermined set ofmetadata and associated parameters for each medical device. The system900 instantiates at a start operation 902, which corresponds tocommunicatively connecting a medical device to a medical device server.In one embodiment, the communicative connection corresponds tointroducing the medical device into a medical device network including amedical device server, such as the network shown in FIG. 1. In a furtherembodiment, the communicative connection corresponds to installation ofa corresponding metadata package onto the medical device, using softwarefor installing a metadata communication layer provided in a softwaredevelopment kit or otherwise provided as consistent with the presentdisclosure.

An association module 904 associates metadata with various medicaldevices in a database of a medical device server. The medical devicesstore corresponding metadata, so that the associated metadatacorresponds to the metadata set on the device. The metadata correspondsto at least one attribute or operational characteristic common to themedical devices, and can be used to distinguish among, identify, andcommunicate with the various medical devices in the medical devicenetwork. In various possible embodiments, operational characteristicsdefined by the metadata include patient information, user or caregiverinformation, control information, drug information, or locationinformation. Additional operational characteristics can be included aswell, such as those described in one or more of the schema of FIGS.11-16. The metadata also corresponds to various events occurring in themedical device, such as power events, alarm events, maintenance events,telemetry events, therapy events, therapy change events, or otherevents. Additional events are described below in FIGS. 17-33.

A storage module 906 stores the metadata on a medical device server orback office components. The medical device server is configured tocommunicate with each of the medical devices by using the metadata andthe metadata-based messaging systems described above in conjunction withFIG. 8. Operational flow proceeds to an end operation 908, whichcorresponds to completion of establishing the communication schemabetween the medical device and medical device server.

FIG. 10 shows further systems and methods for communication between amedical device and a medical device server. The system 1000 of FIG. 10stores metadata common to all medical devices in the medical devicenetworks, and also stores information specific to a subset of themedical devices as well, allowing for customized communications betweenthose medical devices and the medical device server. Operational flow ofthe system 1000 commences at a start operation 1002, which againcorresponds to communicatively connecting a medical device to a medicaldevice server in a medical device network.

Following the start operation 1002, operational flow proceeds to ageneral association module 1004. The general association modulecorresponds to the association module 904 of FIG. 9, in that itassociates metadata defining the characteristics of each medical devicein the medical device network by defining a predetermined set ofmetadata and associated parameters for each medical device. A custommetadata module 1006 associates metadata with one or more medicaldevices, the metadata being specific to that device. Examples of custommetadata include specific power events occurring in a particular type ofmedical device, specialized communication types supported by thosedevices, or other operational parameters which are defined for less thanall of the devices included in a medical device network. A storagemodule 1008 generally corresponds to the storage module 906 of FIG. 9,and stores the general metadata and the custom metadata on the server.

A device selection module 1010 selects one or more of the medicaldevices in the medical device network to communicate with, based on themetadata defining that device stored in the medical device server. Inone embodiment, the device selection module executes upon receiving amessage from the medical device(s). In a further embodiment, the medicaldevice server selects and communicates with one or more medical deviceswithout receiving a previous signaling communication from one of themedical devices.

A communication module 1012 transmits a message to the selected medicaldevice determined in the device selection module 1010. The communicationmodule forms a SOAP-based message for transmission to the medicaldevice, including destination information identifying the medical deviceas well as the data to be transmitted to the medical device. The messageincludes various information identified by the metadata tags defined inthe schema understood by the system 1000, such as those described inFIGS. 11-16 and 19-24, below. Operational flow terminates at an endoperation 1014, which corresponds to completion of transmission of themessage to the medical device.

FIGS. 11-16 show various schema including metadata useable to facilitateextensible communication systems for medical devices and medical deviceservers. The schema are used in the medical device network of FIG. 1 toidentify a variety of medical devices to a medical device server, and toallow the medical device server to communicate with the devices. Theschema include metadata related to various operational parameters, orattributes, common to all of the medical devices in the network orspecialized to one or more of the medical devices. By using the variousschema disclosed, a medical device server can identify a medical device,identify the characteristics of the device, and know how to interoperatewith the device by (1) knowing the device's capabilities and limits and(2) sharing an extensible communications protocol with other medicaldevices.

FIG. 11 shows an identity schema 1100 used to identify variousoperational characteristics of each of the medical devicescommunicatively associated with a medical device server. The identityschema 1100 includes a main table 1102 including a variety of globalparameters, as well as a network table 1104, an access table 1106, andone or more package tables 1108. The main table 1102 includes metadataassociated with a variety of generalized device identificationcharacteristics, including device type, device identifier, sessionidentifier, network identifier, access identifier, and packageacceptance. The device type relates to identification of the type of themedical device such as the manufacturer and model of the device, whilethe device identifier is unique to each device. The session, network,and access identifiers define the connection string to allow the messageto be routed correctly to the medical device. The package identifierindicates whether the medical device is configured to receive packagesfrom the medical device server, and can link to tables indicating thecurrent packages enabled on each device.

The remaining tables, including the network table 1104, access table1106, and package tables 1108 provide additional information related toconnection and capabilities of the medical device, and are linked to themain table by the network identifier, access identifier, and packageidentifier in the main table 1102. The network table 1104 includes thehost, domain, IP address, and port information necessary to define aconnection to the medical device over an Internet connection. The accesstable 1106 includes an IP address and Physical Id corresponding to thespecific networking connection corresponding to the physical device tothe IP address. The package tables 1108 describe additional details ofthe software or firmware package in use by the medical device, such asthe name and version of the software package. Additional detailsregarding package deployment to medical devices are described below inconjunction with FIGS. 25-33.

FIG. 12 shows a control table 1200 which includes elements describingthe logistics of sending messages and tracking those elements betweenthe medical device and medical device server. The control table 1200shown includes message identifier, timestamp, and response metadata. Themessage identifier provides an identification string used to track themessage, and corresponds to the identity of the medical device. Thetimestamp indicates a time at which the message is sent from the medicaldevice server or medical device. The response provides a Booleanindication of whether the message is originating from a medical deviceor is a response from the server. Additional metadata related to messagetracking can be included in the control table as well.

FIG. 13 shows a patient table 1300 used to track patient information forassociation with the medical device. The patient table 1300 includes anidentifier and a name element. The name element holds metadata relatedto the patient's name, and the identifier associates to a statisticallyunique identifier for association with that patient. Otherpatient-related metadata can be included as well.

FIG. 14 shows a location table 1400 used to indicate the location of apatient. The location table 1400 includes metadata defining an aliaselement and a description element. The description element refers to alinguistic description of the location of a patient, such as “HospitalX, Neonatology, Room 1” or some similar entry. The alias elementprovides a shorthand code used to associate the location with themedical device. Additional metadata describing the location of a patientor medical device can be included in the location table 1400 as well.

FIG. 15 shows a drug table 1500 used to indicate the drug, if any,associated with the medical device. The drug table 1500 may or may notbe populated for each medical device, due to the fact that only somemedical devices are capable of delivering drug-based therapies to apatient. The drug table includes metadata related to a drug identifier,a drug name, and a drug concentration. Additional metadata entries canbe used to further identify or describe the drug in use by the medicaldevice.

FIG. 16 shows a user table 1600 corresponding to a doctor, nurse, orother caregiver currently controlling the medical device. The user table1600 includes metadata related to a user identifier and user name, aswell as any additional identifying characteristics of the user necessaryfor operation of the system.

B. Event Logging and Maintenance

Now referring to FIGS. 17-24, systems, methods, and schema are disclosedwhich are used in the medical device network of FIG. 1 to track eventand maintenance information for the various medical devices associatedwith the medical device server. These event-based schema can be used totrack current and historical performance of the medical devices in themedical device network, as well as to maintain the medical devices. Theschema described below define both a messaging system and an ordering ofevent or operational data stored by a medical device server or otherback office components of a medical device network. The event loggingand maintenance tracking schema define specific events or tasksoccurring in the medical device network, as compared to the schemadescribed in part II.A, above, which relate to relatively constantoperational characteristics of the medical devices or server.

FIG. 17 shows methods and systems for receiving event log results fromthe medical device server or back office components using the variousevent-based message schema disclosed in FIGS. 19-24. The system 1700generally executes on a medical device server or other back officecomponents of a medical device network, and provides event log datastored in one or more databases managed by those components to acaregiver or other user.

Operational flow in the system 1700 commences at a start operation 1702,which corresponds to initial operation of the medical device network.Operational flow proceeds to an event receipt module 1704, whichreceives event log data from the various medical devices associated withthe medical device server. The event log data represents eventsoccurring in the medical devices, and can be any of a number of types ofevents, such as power events, telemetry events, alarm events, therapyevents, maintenance events, or other events such as those defined in theschema of FIGS. 19-24.

A sample message body illustrates communication of an event from amedical device to the medical device server, such as is received by theevent receipt module 1704. In the example, the medical device is amedical infusion pump that is sending a power event to the medicaldevice server, indicating that the pump has been turned on:

<env:Body><mds:PowerEvent xmlns:mds=‘mds:xml-schema:soap11’><Trigger>on</Trigger> <Message>Normal Power Up Complete</Message><Timestamp>1900-01-01T00:00:08</Timestamp> <Medfusion4000_Power><Source>AC</Source> <Capacity>90.0%</Capacity> </Medfusion4000_Power ></mds:PowerEvent></env:Body>

This message portion identifies that this is the body of the message,and that it uses the SOAP 1.1 messaging protocol. The messagetransmitted from the pump indicates that power up process has beencompleted, and includes a timestamp assigned by the pump. The variouspower parameters correspond to those parameters included in the powerevent table of FIG. 19, below, and are associated with specific valuesby the medical infusion pump. The message is received from the medicalinfusion pump by the medical device server, and the values are stored inappropriate database tables corresponding to the power event schema.

Analogous messages are sent from the medical device to the medicaldevice server, and responses are sent from the server back to themedical device, as related to the other types of events tracked in themedical device network, as described herein.

A storage module 1706 stores the event log data in a database associatedwith the correct metadata as defined in the message from the medicaldevice to the server. In one embodiment, the storage module 1706 storesevent log data in the event data 318 of FIGS. 3-4.

A request receipt module 1708 receives a request for a subset of theevent log data stored in the medical device server or other back officecomponents. The request received may come from a workstation, portablecomputing device, or other type of computing system. The requestincludes one or more narrowing parameters such as a date range, acaregiver name or identifier, a patient name or identifier, a drug nameor identifier, a specific device, or other types of informationassociated with the event log data. In one example, the request receiptmodule 1708 receives a request for event log data related to delivery ofa specific drug by a medical infusion pump.

A result generation module 1710 generates results based on the specificrequest received by the request receipt module 1708, such as byfiltering event log data held by the medical device server or backoffice components based on the narrowing parameters of the request. Theresult generation module 1710 optionally also transmits the results tothe requesting computing system. Using the example described in therequest receipt module 1708, the medical device server generates a queryconfigured to return event log data related to delivery of theidentified drug by the identified pump. This query can be formed in SQLor some other database querying language, such that the databasemanagement system associated with the medical device server returns thequery results.

Operational flow terminates at an end operation 1712, corresponding tocompletion of generation and transmission of results to the requestingcomputing system.

FIG. 18 shows systems and methods for communicating preventativemaintenance data to a medical device. The system 1800 uses the metadataof FIGS. 11-16, as well as the additional event metadata of FIG. 19-24,to track and communicate maintenance tasks to be performed on one ormore of the medical devices in a medical device network. The variousmessage transmission principles described in conjunction with FIG. 17allow the communication to occur.

The system 1800 commences at a start operation 1802, which correspondsto initial operation of the medical device network. Operational flowproceeds to a storage module 1804, which stores a maintenance scheduleon the medical device server associated with one or more medicaldevices. The maintenance schedule is stored in a database of the medicaldevice server or back office components, and includes both a time valuefor the maintenance reminder events included in the schedule and for themedical device. The maintenance schedule also optionally referencesmaintenance data, such as required operational software updates orvarious other configuration parameters.

In one example, the storage module 1804 stores a maintenance schedulethat includes indications for suggested recalibration of a series ofmedical infusion pumps periodically, or for a specific medical infusionpump. In such an example, the storage module 1804 can store amaintenance schedule provided by the user or manufacturer of the medicalinfusion pump to provide reminders to the user of the pump when theindicated maintenance is scheduled.

A transmission module 1806 transmits a reminder to the one or moremedical devices associated with the maintenance schedule when amaintenance event occurs. The reminder may be a user-readable messagedisplayed on a display associated with the medical infusion pumps,indicating to the caregiver that recalibration is suggested. Or, thereminder may be a trigger of a user-readable message stored on themedical device.

The transmission module 1806 also optionally transmits maintenance dataassociated with the maintenance reminder. In one embodiment of thesystem 1800, the reminder sent by the transmission module 1806 disablesthe medical device. In a further embodiment, the reminder allows themedical device to continue operation. In yet another embodiment, thereminder is transmitted a predetermined time prior to performance of therequired maintenance of the medical device.

Continuing the example of the medical infusion pump from the storagemodule 1804, above, a maintenance event is transmitted to the medicalinfusion pumps. The maintenance event indicates to a medical device thatmaintenance of that device is needed, and includes a reminder messagedisplayed on a display device of the medical infusion pump, such as“Maintenance Required—Please Contact Manufacturer”, or some otherindication of required maintenance. In certain configurations, themaintenance event allows the medical device to continue operation untila caregiver contacts the manufacturer, who may have specificinstructions regarding maintenance and care of the medical device.

Operational flow terminates at an end operation 1808, which correspondsto completion of the transmission of a maintenance reminder and anycorresponding maintenance data to the medical device.

FIGS. 19-24 show event-based schema for communications and responsesbetween medical devices and a medical device server. The schemadisclosed are useable in the medical device network of FIG. 1 to allowthe medical device server and back office components to gather and storeevent log data, as well as to transmit messages to the medical devices.The medical devices and medical device server of the network transmitmessages and event data using the metadata described below to identifythe contents of the messages. The medical device server or back officecomponents store the event data in correspondence with the metadata.

FIG. 19 shows a power event table 1900 and a power event response table1910. The tables 1900, 1910 define metadata used to track various powerevents in a medical device, such as turning the device on, turning thedevice off, battery warnings, and other power-related events. The powerevent table 1900 includes metadata related to a trigger, a message, anda timestamp. The trigger corresponds to a changed event in the medicaldevice, such as turning the device on, off, or updating the poweredstatus of the device. The message describes the specific event thatoccurred in the medical device, such as a low battery warning, anoccurrence of power on event, an occurrence of a power off event, orsome other power-related event. The timestamp indicates the time atwhich the medical device experienced the power event.

The power event response table 1910 includes metadata defining variouspossible responses to the power events received by the medical deviceserver. For example, when the medical device server receives a power onevent, the server may respond that specific maintenance tasks arerequired, or that software or firmware is available to be downloaded.The power event response table includes result, message, session,interval, and package metadata. The result metadata relates to theresult of the power event, such as a changed state of the medicaldevice, or various other server-recognized results of the receivedevent. The message metadata includes a message to be transmitted to themedical device, such as to describe the contents of the responsemessage, for display on a display device associated with the medicaldevice. The session metadata includes information related to thecommunication session between the device and server. The intervalmetadata includes information related to the expected interval betweencommunications from the medical device to the server, which is relatedto server detection of the on-line status of the medical device,described in Part IV, below. The package metadata provides an indicationto the device as to whether new package information is available forthat device, and which may be delivered via the package deploymentmethods and systems of FIGS. 25-33. Additional metadata may be includedin the response table 1910 and the corresponding response message.

FIG. 20 shows an alarm event table 2000 and an alarm event responsetable 2010. Alarm events relate to activation or clearing of an alarmtriggered in a medical device, and the corresponding messages generatedby the device and communicated to the medical device server. Activationor clearing of an alarm in the medical device may relate to detection ofa patient condition detected by the medical device, or may relate to theThe alarm event table 2000 corresponds to the power event table 1900 inthat it also includes trigger, message, and timestamp metadata. In thecase of the alarm event table 2000, the trigger metadata relates to anactivate, clear, or update alarm message. The message and timestampmetadata are used analogously to the corresponding fields of the powerevent table 1900.

The alarm event response table 2010 corresponds to the power eventresponse table 1910. Messages generated using the alarm event responsetable metadata are communicated to the medical device in response toreceipt of an alarm event message. The alarm event response table 2010therefore generally includes a different response than the power eventresponse table 1910, and communicates messages, packages or otherinstructions related to the alarm event.

FIG. 21 shows a maintenance event table 2100 and a maintenance eventresponse table 2110. Maintenance events correspond to specific reactionsof the medical device to an indication that maintenance is required,such as requesting updated operational software, calibration software,or notification messages indicating the maintenance that is required.The maintenance event table 2100 corresponds to data received in amessage from a medical device ready to perform maintenance inconjunction with the medical device server, for situations in whichmaintenance requires a software upgrade or some otherremotely-controllable maintenance event. The maintenance event table2100 corresponds to the power event table 1900 in that it also includestrigger, message, and timestamp metadata. In the case of the maintenanceevent table 2100, the trigger metadata relates to an update or a packageapplied. The message and timestamp metadata are used analogously to thecorresponding fields of the power event table 1900.

The maintenance event response table 2110 also corresponds to the powerevent response table 1910, and is generated by the medical device serveror other back office components. Messages generated using themaintenance event response table metadata are communicated to themedical device in response to receipt of a maintenance event message,and relate to messages, packages or other instructions that occurresponse to the maintenance event, such as additional details regardingthe maintenance required, maintenance schedule information, informationto be displayed by the medical device about the maintenance required.

FIG. 22 shows a telemetry event table 2200 and a telemetry eventresponse table 2210. Telemetry refers to near-continuous streaming ofevent data from a medical device to the medical device server such thatusers with access to the medical device server can monitor operation ofthe medical device remotely in a near real-time fashion. The telemetryevent table 2200 corresponds to the power event table 1900 in that italso includes trigger, message, and timestamp metadata. In the case ofthe telemetry event table 2200, the trigger metadata relates to anupdate event regarding telemetry received from the medical device. Themessage and timestamp metadata are used analogously to the correspondingfields of the power event table 1900.

The telemetry event response table 2210 also corresponds to the powerevent response table 1910, but is generated by the server. Messagesgenerated using the telemetry event response table metadata arecommunicated to the medical device in response to receipt of a telemetryevent message, and communicate messages, packages or other instructionsin response to the telemetry event.

FIG. 23 shows a therapy event table 2300 and a therapy event responsetable 2310. Therapy events relate generally to the start and stop oftherapies or monitoring processes in a medical device. The specifictherapy started or stopped depends upon the type of medical device used,and can include monitoring, drug delivery, or other therapies. Thetherapy event table 2300 corresponds to the power event table 1900 inthat it also includes trigger, message, and timestamp metadata. In thecase of the therapy event table 2300, the trigger metadata relates to asetup, begin, end or update therapy event as related to initializationor ending of a therapy by a medical device. The message and timestampmetadata are used analogously to the corresponding fields of the powerevent table 1900.

The therapy event response table 2310 also corresponds to the powerevent response table 1910, but is generated by the server. Messagesgenerated using the therapy event response table metadata arecommunicated to the medical device in response to receipt of a therapyevent message, and communicate messages, packages or other instructionsin response to the therapy event.

FIG. 24 shows a therapy change event table 2400 and a therapy changeevent response table 2410. Therapy change events relate generally tochanges in therapies operating on a medical device, and are related totherapy events, discussed above. Therapy change events include, forexample, changed parameters related to monitoring or delivering oftherapies, such as changed drug delivery rates. The therapy change eventtable 2400 corresponds to the power event table 1900 in that it alsoincludes trigger, message, and timestamp metadata. In the therapy changeevent table 2400, the trigger metadata relates to an override, warning,abandon, or update event as related to a therapy change. The message andtimestamp metadata are used analogously to the corresponding fields ofthe power event table 1900.

The therapy change event response table 2410 also corresponds to thepower event response table 1910, but is generated by the server.Messages generated using the therapy change event response tablemetadata are communicated to the medical device in response to receiptof a therapy event message, and communicate messages, packages or otherinstructions in response to the therapy change event.

C. Package Deployment

Referring back to FIG. 11, various systems and methods exist fordeploying packages to medical devices from a medical device server. Thepackages deployed may include firmware upgrades, maintenanceinformation, new or changed parameters for therapies, or other softwareupgrades or changes to the medical devices in a medical device network.In a possible embodiment, a package can be used to reprogram the medicaldevice to which it is sent with any of the possible types of packagedata. Medical devices capable of receiving package data indicate thiscapability in the main table 1102 and package tables 1108. The maintable 1102 indicates the capability of the device to receive a package,and the package tables 1108 include information related to the currentpackage information stored at the medical device for use in operation ofthe medical device. Package delivery, as discussed in greater detailbelow, occurs in response to a message, and is initiated using thepackage data identifier in the event response tables 1910-2410 toindicate to the medical device that a package is available for delivery.

Referring now to FIG. 25, an example structure of a package 2500 used indeployment of information to a medical device is shown. The package 2500includes a server header 2502, a vendor header 2504, and information2506 to be delivered to the medical device. The server header 2502 isthe portion of the package understood by the medical device server. Theserver header 2502 is in a common format to all packages, and containsidentification information related to the type of device configured toreceive the package, as well as the source of the package. Additionalinformation, such as package size, encryption format, or encryption keylocation information may be included in the server header 2502 as well.In one embodiment, the server header 2502 is a 256 byte blockincorporated into the package.

The vendor header 2504 contains vendor specific information related touse of the package within the medical device receiving the package. Thevendor providing the package to the medical device server is generallythe manufacturer or maintenance company associated with the medicaldevice intended to receive the package, so the vendor will format thevendor header 2504 in a manner understandable to the medical devices itmanufactures. The vendor header generally includes information relatedto the size of the information 2506, as well as the location ofencryption information 2508 within the information. The encryptioninformation 2508 can be used by the medical device to decrypt theinformation, which is generally stored in the medical device server inan encrypted form.

The information 2506 generally includes any software to be transferredfrom the medical device server to a medical device, such as a firmwareupgrade, a file including therapy parameters, or other binary data. Thepackage delivery system 2500 is not dependent upon the specific formatof the vendor header 2504 or the information 2506. The information 2506is generally stored in an encrypted form on the medical device server.When transferred to a medical device, the information 2506 is decryptedby the medical device by locating the encryption information 2508 basedon information in the vendor header 2504.

FIG. 26 shows systems and methods for deploying package data from amedical device server to medical devices. The system 2600 is configuredto distribute a package, such as the package 2500 of FIG. 5, to amedical device in response to a message received from the medicaldevice.

Operational flow within the system 2600 commences at a start module2600, which corresponds to receipt of package information from a vendorof a medical device, an administrator of the medical device, or anotherentity having familiarity with the operation of the medical device. Astorage module 2604 stores the received package in the medical deviceserver. The storage module 2604 can also set an alert or other variablefor a medical device such that the next time the medical devicecommunicates with the server, an indication of the existence of thepackage is included in the response to the medical device. In oneembodiment, the storage module 2604 encrypts the package while stored onthe medical device server or back office components, and either themedical device server or the medical device itself decrypts the messagewhen the package is to be used or transmitted. In a further embodiment,the storage module 2604 leaves the package unencrypted when it is storedon the medical device server or back office components.

A message receipt module 2606 receives at the medical device server amessage from a medical device. The message may be any of a number oftypes of messages, such as the power, maintenance, alarm, telemetry,therapy, or therapy change event messages described above in FIGS.19-24. Additional message types are possible as well.

An indication module 2608 indicates to the medical device that a packageis intended for delivery to that device. In one embodiment, theindication module 2608 sets a parameter in a message response indicatingthe existence of a package. For example, the indication module 2608 canset a parameter in the package metadata included in the event responsemessages 1910-2410 of FIGS. 19-24. Additional methods of indicating theexistence of a package are possible as well, such as transmission of aspecific message related to package deployment, a package request by themedical device, or other methods.

A request module 2610 receives a request from the medical device toreceive the package. The request module 2610 may include one or moresteps of requesting information about the package to verify at themedical device that the package should be accepted. In a possibleembodiment, the request module 2610 transmits a package informationrequest message, using metadata as shown in FIG. 27. In such anembodiment, the request module 2610 optionally also transmits a packagedata request message separate from the package information requestmessage, the package data request message transmitted following receiptof package information describing the package contents from the medicaldevice server. In further embodiments, the request module 2610 receivesa request as shown in FIG. 29 or 31.

A delivery module 2612 delivers the requested package to the medicaldevice. The format of the package delivery message can be as shown inFIG. 30 or 32. Operational flow terminates at an end operation 2614,which corresponds to completion of the package transmission to themedical device.

FIGS. 27-32 show schema including metadata used in messages and tablesin a medical device network, such as the one shown in FIG. 1, to deploypackages from a medical device server to a medical device. The schemadisplay various request and response scenarios in which a medical devicerequests delivery of package information and receives the requestedinformation in response. One or more messages may be sent between themedical device and the medical device server prior to delivery of thepackage and its enclosed data.

FIG. 27 shows a package information request table 2700 includingmetadata used to request information about a package that is availableto be deployed to a medical device. The medical device is notified of anavailable package based on a previous response from the medical deviceserver, as reflecting information in the main table 1102 or packagetables 1108 related to that device in the medical device server. Themetadata in the table 2700 includes a package identifier, which is usedby a medical device to identify the package and request informationabout its contents. Additional metadata related to the package may beincluded in the table 2700 and message from the medical device as well.

FIG. 28 shows a package information request response table 2800including metadata used in describing a package available to be deployedto a medical device. The metadata in the table 2800 includes the packageidentifier, corresponding to the package identifier in the packageinformation request table 2700, and also includes package informationmetadata. The package information metadata links to a packageinformation table 2802, which contains name and version metadata. Valuesassociated with the name and version metadata describe the package, suchthat the medical device can determine whether to request deployment ofthe package.

FIG. 29 shows a package data request table 2900 including metadata usedin requesting package data from a medical device server. The packagedata request table 2900 includes package identifier and response typemetadata. The package identifier represents a unique identifier for thepackage available for deployment to the medical device. The responsetype represents an identifier indicating the desired delivery format ofthe package data. In one embodiment, the package data can be deliveredto the medical device in either a plain text format or using an xopformat.

FIG. 30 shows a package data request response table 3000 includingmetadata used in deploying a package to a medical device. The metadataincluded in the package data request response table 3000 includes apackage identifier and a package binary data field. The packageidentifier identifies the package referred to in FIG. 29, and thepackage binary data field denotes the binary data representing thepackage being delivered to the medical device. The package binary datafield can optionally link to a separate package binary data table 3002containing the package binary data for delivery to a medical device. Inone embodiment, the package delivered to the medical device is thepackage 2500 of FIG. 25.

FIG. 31 shows a package request table 3100. The package request table3100 corresponds to the package data request table 2900 of FIG. 29combined with the package information request table 2700 of FIG. 27. Thepackage request table 3100 can be used by the medical device in aninstance in which the medical device does not need to validate thepackage information prior to downloading the package. The packagerequest table 3100 includes a package identifier and a response type,similar to the package data request table 2900, but indicates byrequesting the entire package that package information and package datamessages need not be separated.

FIG. 32 shows a package request response table 3200, representing theschema of a message from the medical device server sent in response to amessage of the form reflected by the package request table 3100 of FIG.31. The package request response table includes package identifier,package information, and package binary metadata. The packageinformation metadata links to a package information table 3202containing name and version metadata associated to the package data. Thepackage binary metadata links to a package binary table 3204, whichincludes metadata corresponding to the package to be deployed to themedical device.

D. Time Management

Referring now to FIGS. 33-35, systems and methods for time management ina medical device network are shown. Because the medical device networkcan vary in size or configuration, the time management systems describedare configured to extend across various business entities, variouslocations, and various time zones. The systems and methods describedprovide a uniform way to synchronize time tracking in medical devicesand a medical device server located in one or more locations or timezones.

FIG. 33 shows a time messaging schema 3300 useable to track medicaldevice time at the medical device server, and also transmit timesynchronization messages between a medical device and a medical deviceserver. The time schema 3300 includes a time request table 3302, a timerequest response table 3304, and a system time table 3306. The timerequest table 3302 optionally includes no metadata, but represents atime request response sent from a medical device to the medical deviceserver for synchronization of the medical device time with the timestored in the server or back office components. The time requestresponse table 3304 includes system time metadata, associated with thesystem time value stored on the medical device server. The system timemetadata optionally links to a system time table 3306, which contains atime value useable to synchronize the time of the medical device withthe time received from the medical device server. Additional metadata orother information useable to assist in time synchronization can be usedas well.

FIG. 34 shows methods and systems for time synchronization of medicaldevices and a medical device server within a medical device network.Operational flow in the system 3400 commences at a start operation 3402,corresponding to initial operation of the medical device network. Aserver time maintenance module 3404 maintains a global time value in theserver that is to be used to synchronize the time values of the medicaldevices communicatively connected thereto.

A server time transmission module 3406 transmits the server time to oneor more medical devices in the medical device network. In oneembodiment, the server time transmission module 3406 transmits theserver time value to a medical device in response to a request messagefrom that medical device. In such an embodiment, the request message maybe of a form shown in the time request table 3302 of FIG. 33, above.

In a further embodiment, the transmission module 3406 converts theserver time value to a localized server time value based on the timezone of the location of the medical device. This conversion may takeplace if the server resides in a different time zone from the medicaldevice. The server and medical device thereby have a synchronized timevalue that is converted to the appropriate time zone. One possibleimplementation of this embodiment converts all times to the UniversalTime Protocol upon transmission from the server, and the destinationmedical device reconverts the time value to the local time of thatdestination device's location. Other time zone conversions, such as fromthe local time of the medical device server to the local time of themedical device, are possible as well.

A replacement module 3408 replaces the device time in the medical devicewith the server time value received from the medical device server. Thereplacement module 3408 uses the time-adjusted server time value,configured to be used at the location of the medical device. An optionalconfirmation module 3410 sends a confirmation message to the medicaldevice server indicating that the medical device is successfullysynchronized to the server, allowing the server to track which medicaldevices have been successfully synchronized with the server. Operationalflow terminates at an end operation 3412, corresponding to completion ofthe time synchronization process.

Referring now to FIG. 35, methods and systems for synchronizing eventlog data are disclosed. The system 3500 accommodates event log datareceived from medical devices located in different locations in aplurality of time zones. The event log data is configured such that thelocal time stamp of the event log data represents the time zone in whichthat device resides, so event logs from different time zones having thesame time stamp in actuality occurred at different times. The system3500 compensates for this discrepancy when storing event log data, andalso when providing it to users for review. Operational flow within thesystem 3500 commences at a start operation 3502, corresponding toinitial communication of event data from medical devices to the medicaldevice server.

A receipt module 3504 corresponds to the medical device server receivingevent log data from one or more of the medical devices. As describedabove, the event log data includes various details regarding varioustypes of events, such as therapy events, alarm events, maintenanceevents, telemetry events, or other types of events, each of which areassociated with a time stamp reflecting the current time value of themedical device, reflecting the local time zone of that device. A timezone modification module 3506 converts the time stamp information fromthe local time zone of the medical device to a constant time zone. Inone embodiment, the time zone modification module 3506 converts the timestamp to the Universal Time Protocol (UTP). A storage module 3508 storesthe converted time stamp and associated event log data in the medicaldevice server or back office components.

An optional global tracking module 3510 tracks global events using theuniform time zone information. For example, a user desiring to trackevents that occur at single instantaneous moment across all time zonescan track global events using the Universal Time Protocol to maintain astandard time across all time zones. The user sends a request for eventlog data related to the global events stored on the server, and receivesevent log information with a time stamp having constant time zoneinformation.

A request local event module 3512 receives a request for local eventdata, including types of event data associated with the time zone inwhich the event occurs. Examples of time zone specific events caninclude events timed to occur at the beginning or end of a shift at ahospital, or other local events. The request local event module 3512generates a query for the event data requested, and returns resultsincluding event log data. A conversion module 3514 converts the uniformtime zone information to local time zone information based on thelocation of the medical device from which the event log data wasrecorded. The conversion module 3514 optionally generates a report fromthe event log data for distributing to a requesting user, including thecompensated local time event log. Operational flow within the system3500 is terminated at an end operation 3516, which corresponds tocompletion of the conversion module 3514.

IV. Remote User to Server Communication

Referring now to FIGS. 36-66, a generalized web service architecture isdisclosed which manages user access to a medical device server in amedical device network, such as the one shown in FIG. 1. The web servicearchitecture allows remote user to server communication, to provide dataaccess and programming capabilities related to medical devices in themedical device network of FIG. 1. For example, users can performadministrative tasks, administer software updates to medical devices,access event and operational records, perform maintenance, changetherapies, and view near real-time operation of the medical deviceswhile remotely located from the devices. These functions, and others,are described below.

FIG. 36 shows an overall web service architecture 3600, shown as asubsystem of the possible software architectures of the medical devicenetwork in FIGS. 3-4. The web service architecture includes various webmodules or services configured to validate users and provide access todata stored on the medical device server. In a possible embodiment, theweb service architecture is implemented in a .NET architecture usingInternet Information Server, by Microsoft Corporation.

The web service architecture 3600 includes an administrative web service3602, an operations web service 3604, and an event tracking web service3606. The administrative web service 3602 validates users of the medicaldevice server, and includes functional interfaces for logging in,logging out, and changing a user password. The administrative webservice 3602 tracks information related to products, customers, contactinformation, medical devices associated with the customers, useraccounts associated with a customer, and other variables. Theadministrative web service 3602 uses this tracked information tovalidate specific users, each of whom is associated with a specifichealth care facility, referred to in the administrative web service as acustomer. A specific implementation class of the administrative webservice 3602 is described in Part IV.A, below.

The operations web service 3604 provides access to operational data ofthe medical devices, such as operational data regarding therapy deliveryor monitoring data. The operations web service 3604 tracks the varioustherapy states occurring in a medical device, and enables a messagingsequence that can occur to trigger or track a therapy event in a medicaldevice. A specific implementation of the operations web service 3604 isdescribed in Part IV.B, below.

The event tracking web service 3606 tracks various event data occurringin a medical device, such as telemetry data received by a medical deviceserver. The event tracking web service 3606 enables users to viewnear-real time activity of a medical device while located remote fromthe medical device, and allows the user to determine the on-line statusof the medical device. A specific implementation of the event trackingweb service 3606 is described in Part IV.C, below.

A. Administration

Referring now to FIGS. 37-41, systems and reports for definition and useof an administrative web service are shown. FIG. 37 shows an exemplaryclass structure defining an administrative web service 3700. Theadministrative web service 3700 provides a possible embodiment of theadministrative web service 3602 of FIG. 36, and is accessible via any ofa number of user interfaces, such as the administration web forms 324 ofFIG. 3. The administrative web service 3700 includes an authenticationclass 3702, an authorization class 3704, a user class 3706, a role class3708, a license class 3710, a resource class 3712, a metadata class3714, and an entity settings class 3716. Each of the classes includes anumber of functions remotely accessible via the internet and web-baseduser interfaces to perform administrative tasks. Functionality of thevarious classes is described below.

The authentication class 3702 provides the initial access to theadministrative web service 3700, and includes login and logoutfunctionality. The authorization class 3704 includes a variety ofresource control functions to ensure that two users are not reading fromand writing to the same data concurrently, or otherwise causing dataconflicts. The resource control functions incorporated into theauthorization class 3704 include read, write, create, delete, and accesspermission functions. Other functions may be incorporated into theauthorization class 3704 as well.

Each of the other classes link to the authorization class 3704, and eachrequests read or write access to the data protected by the authorizationclass 3704. The user class 3706 allows the system to perform varioususer administration tasks, such as creating new users, editing userinformation, changing passwords, deleting users, defining user roles,and retrieving user histories. Other functions are possible as well. Therole class 3708 defines roles assignable to users, and includes theability to create, update, delete or retrieve various roles defined inthe administration data. Roles may correspond to various classes ofindividuals who can access data managed by the medical device server andback office components, such as doctors, nurses, or healthcareadministrators. Roles may also correspond to the various entities withwhich the individuals are associated.

The license class 3710 defines licenses installed into the system tocontrol the number of users able to log in at once, as well as to defineusage models for various accounts. For example, a particular account mayallow only a limited number of individuals to view telemetry data or toaccess therapy records at once, or may define a way of charging acustomer for tracked usage of the medical device server or other backoffice components.

The resource class 3712 allows an administrator to add and deleteresources, which correspond to the specific functional areas of themedical device server. The metadata class 3714 provides the underlyingfunctionality for installing metadata into either the administrationsystem, such as custom metadata corresponding to a newly introducedmedical device, or into a newly introduced medical device itself.Exemplary interfaces for installation of metadata are shown below inFIGS. 42-43. The entity settings class 3716 allows writing and retrievalof entity settings. Additional administrative functionality, includingadditional classes, may be incorporated into the administrative webservice 3700 as well.

FIGS. 38-41 display sample administrative reports accessible to a user.The administrative reports of FIGS. 38-41 correspond to the reports 326shown in FIGS. 3-4, and are derived from information stored in the datawarehouse 322 related to administrative events logged by the medicaldevice server. In a possible embodiment of the present disclosure, thevarious reports are generated using SQL Server Reporting Services, byMicrosoft Corporation. Other reporting and business intelligencesoftware may be used as well.

FIG. 38 displays an administration tracking event report 3800. Theadministration tracking event report displays detailed informationregarding administration events, such as user access and connection tothe medical device server. The number and contents of entries in thereport correspond to data from the administration data 316 of FIG. 3that match the query presented to the administrative web service. Theadministration tracking event report includes time and date information3802, application information 3804, and message information 3806.Additional information, such as the code information, time zoneindicator, and other information can be optionally included in thereport 3800.

The time and date information 3802 display the time stamp informationrelated to the event tracked by the administrative module. The time anddate information 3802 display on the report in varying formats,depending upon whether a user chooses a local time zone option or a GMTnormalized time option. In the report 3800 shown, the local time zoneoption is selected.

The application information 3804 indicates the service or handleraccessed, and the message 3806 indicates the action taken with respectto that service or handler. In the example shown, exemplary connectionevents are shown for two medical device servers, labeled “MDS:Mds01” and“MDS:Mds02”.

FIG. 39 displays a security event report 3900. The security event report3900 corresponds generally to the administration tracking event report3800, but includes events related to security of the medical deviceserver rather than access to it. The security event report 3900 includestime and date information 3902, application information 3904, andmessage information 3906, each of which have the same functionality asin the administration tracking event report 3800.

FIG. 40 displays a security event trending report 4000. The securityevent trending report 4000 displays a chart of security related eventsover time. In the embodiment shown, the security event trending report4000 displays a bar chart showing the frequency of security events bymonth. Other configurations displaying trends in security events arepossible as well.

FIG. 41 displays a user history report 4100. The user history reportdisplays a chronologically ordered list of events logged regarding oneor more users. Each entry in the list includes time and date information4102, a sorting code 4104, a username 4106 corresponding to the activeuser, and a message 4108 related to the action taken by that user. Anoptional details entry 4110 displays additional information associatedwith the history information, in raw form, such as the session key,location, name, location, or other activities occurring in the userhistory.

1. Metadata and Package Deployment Interfaces

Referring now to FIGS. 42-50, various methods of programming the medicaldevice server and medical device with metadata, firmware, or otherbinary data are shown. FIGS. 42-46 display administrative forms useableto perform various administrative tasks in the medical device server,such as providing or removing metadata or packages, intended forconfiguration of the medical device server or medical devices,respectively. The administrative forms can correspond to forms generatedby the administrative applications 324 of FIGS. 3-4. FIGS. 47-50 displayreports displaying the results of installation of the metadata andpackages, and are a subset of the reports 326 available from the datawarehouse 322 in FIGS. 3-4.

FIGS. 42-43 display user interfaces configured to allow anadministrative user to manage metadata installed into the medical deviceserver, as described above in Parts III.A and III.B. FIG. 42 shows aninitial user interface 4200 showing the metadata packages eithercurrently installed into the medical device server or available to beinstalled. A listing area 4202 lists the packages, in this casedisplayed as “Virtual Infusion Pump”, “Virtual Patient Monitor”, and“Medfusion 4000”. Check boxes 4204 in the listing area allow userselection of one or more of the installed packages, an install button4206 installs the packages into the medical device server, and anuninstall button 4208 removes metadata packages from the medical deviceserver.

FIG. 43 displays a metadata installation interface 4300 configured toallow a user to browse for a metadata file and install that file ontothe medical device server. The metadata installation interface 4300appears following selection of one of the types of medical devicespresent in the system in the user interface 4200, and allows the user toselect and install a metadata file associated with the previousselection of metadata using the initial user interface 4200.

FIG. 44 displays a package deployment interface 4400 providingdeployment of packages for distribution to one or more medical devices,as described above in Part III.C. The package deployment interface 4400generally corresponds to the metadata installation interface 4200 ofFIG. 42, but relates to software to be installed onto a medical device,rather than into the medical device server. A listing area 4402 liststhe packages, in this case displayed as “Simple Infusion Pump” or“TestPackage”. Check boxes 4404 in the listing area allow user selectionof one or more of the installed packages, a deploy button 4406 deploysthe packages into the medical device server, and an uninstall button4408 removes the packages from the medical device server.

Upon selection of the deploy button 4406, a user interface 4500 shown inFIG. 45 is displayed. The user interface 4500 allows systemadministrators to enter a package deployment name into a name field4502, and also allows the administrator to enter a start time and endtime, into start and end fields 4504, 4506, respectively. The userinterface further allows the system administrator to select a packagedeployment file to use in a package deployment file selection field4508. The system administration presses a deploy button 4510 to deploythe package, or a cancel button 4512 to cancel deployment.

Upon selection of the deploy button 4510, a further user interface 4600shown in FIG. 46 is displayed to allow user verification that thecorrect package has been selected for download to medical devices. Theuser interface 4600 displays package deployment details in a packageinformation field 4502, including the selected start time, end time, andtarget type as entered in the previous user interfaces 4400, 4500. Theuser interface 4600 further displays vendor properties in a vendor field4504, such as the vendor identifier, name, and version of the vendorpackage.

FIGS. 47-50 display various reports generated from the data warehouse322 of FIGS. 3-4, as related to metadata-defined event messages orpackage deployment. FIG. 47-48 relate to message handling and debuggingof faulty messages received from a medical device. FIGS. 49-50 displaypackage deployment reports, incorporating records of successful andunsuccessful deployment of software or other binary data to medicaldevices.

FIG. 47 displays a quarantine report 4700, which displays achronological list of the quarantined messages received by the medicaldevice server. The quarantine report 4700 includes time and dateinformation 4702, state information 4704, and message information 4706.The time and date information 4702 display the time stamp informationrelated to the quarantine event tracked by the medical device server.The time and date information 4702 display on the report in varyingformats, depending upon whether a user chooses a local time zone optionor a GMT normalized time option. In the report 4700 shown, the localtime zone option is selected.

The state information 4704 relates to the state of the quarantinedmessage, such as whether it is a new message, a released message, or areinserted message. New messages refer to newly located problematicmessages, while released messages correspond to messages which cannot beresolved and must be dropped. Reinserted messages refer to thosemessages which are reintroduced to the message server in case themedical device is awaiting a response from the server.

The message information 4706 describes the error occurring in themessage transfer. Various error messages are possible, generallyrelating to the ability of the medical device server to understand themessage received from a medical device.

FIG. 48 displays a quarantine detail report 4800, which is configured todisplay the details of a specific quarantined message received by themedical device server. The quarantine detail report includes an errorfield 4802 including the error information displayed on the quarantinereport 4700, and a source field 4804 which displays the metadata andvalues included in the message, for user debugging or correction ofmessage activity in the medical device server. Additional informationcan be displayed regarding the quarantined message as well.

FIG. 49 displays a package deployment report 4900 showing packagedeployments known to the medical device server, with an associated listof medical devices of various types and the status of the packagedeployment to each of the medical devices. The package deployment reportincludes one or more package deployment entries 4902, each includingname and version information related to the specific package beingdeployed to that type of device. Each of the package entries includesdevice sub-entries 4904, each of which relates to a specific devicequalifying for the generalized package deployment. The sub-entries eachinclude host name information 4906, physical identification information4908, notification information 4910, transfer information 4912, andcompletion information 4914. The host name information 4906 correspondsto the medical device server providing the package to the device. Thephysical identification information 4908 displays the unique identifierassociated with the medical device. The notification information 4910displays the date and time at which the medical device was notified thatthe package was available. The transfer information 4912 displays thedate and time at which the package was successfully transferred to themedical device. The completion information 4914 displays the full dateand time at which the package was successfully applied to the medicaldevice.

Additional information can be tracked for each package deployment. Forexample, in an instance in which a package fails to deploy, an errorindication 4916 displays an indication of an error, and a result of theerror.

FIG. 50 displays a package deployment error report 5000. The packagedeployment error report 5000 provides a detailed event history for thespecific packages and corresponding devices for which a packagedeployment fails. The package deployment error report 5000 displays atitle 5002 including the target medical device type and packageidentifier. The title also optionally displays a name associated withthe package deployment.

The package deployment error report 5000 displays time and dateinformation 5004, optional host information 5006, physical identifierinformation 5008, and message information 5010. The time and dateinformation 5004 indicate when the error in the package deploymentoccurred. The optional host name information 5006 displays the networkname in which the medical device is located. The physical identifierinformation 5008 includes the identifier associated with the medicaldevice. The message information 5010 displays the message associatedwith the package deployment error. Additional information regarding thedeployment error may be included in the report 5000 as well.

2. Maintenance/Faults

Referring now to FIGS. 51-53, reports related to maintenance and faultsof medical devices are shown. The reports provide user access to recordsof maintenance performed on the medical devices as well as informationrelated to medical device failures and trends in those failures.Additional reports related to maintenance or faults may be incorporatedas well, and correspond to the maintenance event data collected by themedical device server, as described above in Part III.B. In a possibleembodiment, one or more of the reports of FIGS. 51-53 correspond to themaintenance forms 330 of FIGS. 3-4.

FIG. 51 shows a medical device maintenance report 5100 listingmaintenance records for various medical devices. The medical devicemaintenance report 5100 includes type entries 5102 corresponding tovarious types of medical devices, and device sub-entries 5104corresponding to specific medical devices. In the embodiment shown, thetype entries 5102 are the “MedFusion 4000” and “Titan” entries, whilethe device sub-entries 5104 are the individual rows within each type.

Within each sub-entry 5104, there exists host name information 5106,physical identifier information 5108, version information 5110, packageinformation 5112, and preventative maintenance date information 5114.The host information 5106 displays the network associated with themedical device. The physical identifier 5108 displays the uniqueidentifier associated with the medical device. The version information5110 displays one or more version numbers associated with the medicaldevice. The package information 5112 displays packages being used by themedical device. The preventative maintenance information 5114 displays adate at which the medical device is due for preventative maintenance.Additional information can be displayed within each sub-entry 5104 aswell.

FIG. 52 shows a medical device fault report 5200. The medical devicefault report 5200 displays events related to medical device faultscommunicated to a medical device server, such as due to a faultybattery, motor, or other mechanical component. The medical device faultreport 5200 includes time and date information 5202, host information5204, physical identifier information 5206, and message information5208. Use of the information 5202-5208 is analogous to the correspondingelements in the package deployment error report 5000 of FIG. 50, butrelated to medical device fault events. For example, in the medicaldevice fault report 5200, the message information includes device faultevent information, such as motor, battery, or other mechanical faults ofa medical device.

FIG. 53 shows a medical device fault trending report 5300. The medicaldevice fault trending report 5300 displays a chart of medical devicefault related events over time. The medical device fault trending report5300 provides users with an indication of repeated errors in a medicaldevice, or other detectable trends in medical device faults. In theembodiment shown, the medical device fault trending report 5300 displaysa bar chart showing the frequency of device fault events by month. Otherconfigurations displaying trends in device fault events are possible aswell.

B. Operations Web Service: Operation and Control of Therapy States

FIGS. 54-62 disclose various aspects of the operations web service 3604of FIG. 36. Specifically, the figures show systems, methods, and reportsfor remote operation of the medical devices in a medical device network.In one possible embodiment, the systems and methods describe tracking ofchanged therapy parameters in a medical device by tracking original,updated, and final parameters of the medical device.

FIG. 54 shows a flowchart of methods and systems for tracking therapyorder states in a medical device server. Therapy orders refer tocommands to a medical device to provide a therapy to a patient. Thesystem 5400 includes states corresponding to the various possible statesexperienced in the medical device during execution of the therapy order.

Operational flow within the system 5400 commences at a start node 5402,which corresponds to introduction of a new therapy order into themedical device or medical device server. Once the therapy order isintroduced, the system 5400 enters a new state 5404, indicating that thetherapy order is newly introduced and has not yet been executed by themedical device. When the system 5400 is in the new state 5404, a userhas the option to cancel the therapy order. If the user chooses tocancel the therapy order, operational flow in the system 5400 proceedsto a canceled state 5406. From the canceled state, operational flowproceeds to an end node 5408 corresponding to completion of the therapymodule. At the end node 5408, operational flow terminates and therapydelivery events tracked using the medical device server continue to bestored for review by a user.

If the user chooses not to cancel the therapy order while the system5400 is in the new state, operational flow proceeds to an assisted setupstate 5410. The assisted setup state 5410 attempts to assist in settingup the therapy parameters. If the assisted setup is unsuccessfuloperational flow branches to a failed state 5412. The failed state 5412stores an error message indicating that the assisted setup processfailed. Operational flow proceeds from the failed state 5412 to the endnode 5408.

If the assisted setup state 5410 is successful in setting up therapyparameters, operational flow branches to a setup state 5414. The setupstate 5414 indicates that the therapy is successfully set up in themedical device, and is ready for delivery to a patient.

A begin therapy event, optionally sent from the medical device server orgenerated at the medical device, triggers the system 5400 to proceed toa started state 5416, which corresponds to starting the therapy deliveryin the medical device. An end therapy event received from the medicaldevice or medical device server causes operational flow in the system5400 to proceed to a complete state 5418, indicating that delivery ofthe therapy is complete. Operational flow next proceeds to the end node5408.

FIG. 55 shows an exemplary class structure defining a therapy service5500. The therapy service 5500 illustrates a portion of thefunctionality of the operations web service module 3604. The therapyservice 5500 links to and uses a variety of functions from theadministrative web service 3700 of FIG. 37.

The therapy service 5500 includes a therapy order class 5502, a therapyorder rule utility 5504, and a therapy order action enumeration 5506.The therapy order class 5502 includes a variety of therapy orderoperations for starting, stopping, and defining various therapies to bedelivered by medical devices in the medical device network in which thetherapy service 5500 operates. The therapy order operations includetherapy creation, therapy update, therapy cancel, therapy execute, andtherapy retrieval operations. Additional therapy order operations can beincluded in the therapy order class 5502 as well.

The therapy order rule utility 5504 provides expressions and actionsrelated to execution of the therapy order, including various parametersand commands required for execution of the therapy. The therapy orderaction enumeration 5506 provides advisory messages used during selectionand/or execution of a therapy order.

FIG. 56 displays exemplary message exchange processes 5600, 5620, 5640,and 5660 performed between a therapy order management application 5602,an operations web service 5604 such as the one shown in FIG. 36, amedical device server 5606 as disclosed above in FIGS. 3-4, and amedical device 5608, such as shown in FIG. 2. The therapy ordermanagement application 5602 can be any application configured tointerface with the operations web service to communicate therapy ordersand other messages to the operations service 5604 and medical deviceserver 5608.

A first message exchange process 5600 illustrates the therapy ordermanagement application 5602 transmitting a create therapy order message5610 to the operations web service 5604. The operations web service 5604verifies the therapy information and stores the therapy order inoperations data. The operations web service 5604 also responds 5612 byindicating success or failure of the message.

A second message exchange process 5620 illustrates the therapy ordermanagement application 5602 later in time transmitting a therapy orderupdate message or a therapy order cancellation message 5622. Theoperations web service 5604 verifies the therapy information, andupdates or cancels the therapy order according to the message. Theoperations web service 5604 also responds 5624 by indicating success orfailure of the message.

A third message exchange process 5640 occurring after the first messageexchange process 5600 illustrates the therapy order managementapplication 5602 transmitting a message 5642 indicating that the therapyorder should be executed. The therapy order management application 5602transmits an execute therapy order message 5642 to the operations webservice 5604, which verifies the therapy order and in turn forwards thetherapy order message 5642 to the medical device server 5606. Themedical device server 5606 relays the therapy order message 5642 to amedical device 5608.

The medical device 5608 transmits a message 5644 indicating the successor failure of receipt of the therapy order message 5642. The medicaldevice server 5606 and operations web service 5604 relay the message5644 back to the order trigger application 5602.

At a time after the medical device transmits the message 5644, themedical device 5608 initiates a fourth messaging process 5660 in whichthe medical device transmits a therapy begin message 5662 to the medicaldevice server 5608, indicating that the medical device has begundelivering the therapy to a patient. The medical device server 5608transmits the message 5662 to the operations web service 5604, whichupdates the therapy order state. The medical device server also relaysthe message 5662 to an event tracking web service 5605, such as the onein FIG. 36, to store a therapy delivery event in an event history log.Both the event tracking web service 5605 and the operations web service5604 transmit response messages 5664 indicating the success or failureof receipt of the therapy begin message 5662.

Additional events triggered by the medical device, such as a therapycompletion event or alarm, transmit among the components 5602-5608analogously to the messaging process 5660. Further, additional messagingschema can be included as well.

FIG. 57 shows methods and systems for tracking changed parameters in amedical device, such as a medical infusion pump. The system 5700communicates original, updated, and final parameter values used foroperation of the medical device, using metadata as described herein toidentify the various changes in parameters. The system 5700 commences ata start operation 5702, which corresponds to initiation of a therapy ina medical device. The therapy initiated in the medical device includesparameters needing parameter values to define various aspects of thetherapy. For example, in a therapy delivered by a medical infusion pump,various parameters include basal rates, bolus rates, thresholds, andvarious other parameters.

An original parameter receipt module 5704 receives an original parametervalue from a medical device. The original parameter is a parameter setin a medical device prior to receipt of a different parameter by thatdevice, and can be any type of operational parameter related to deliveryof a therapy or monitoring provided by the medical device. An updatedparameter receipt module 5706 receives an updated parameter value fromthe medical device corresponding to a change from the originalparameter. The updated parameter value is a new parameter value changingthe operation of the medical device. The updated parameter value relatesto the same parameter as the original parameter. A final parameterreceipt module 5708 receives a final parameter value from the medicaldevice. The final parameter value is the parameter value the medicaldevice will use for therapy and monitoring after the device isreprogrammed with the updated parameter value. The final parameter valuemay be the same as the updated parameter value, or may be differentbased on, for example, various hard and soft limits set for parameterswithin the medical device. In various embodiments, the receipt modules5704-5708 may occur concurrently or sequentially, and may be included inone or more messages from the medical device to the medical deviceserver.

A parameter storage module 5710 stores the original, updated, and finalparameter values in memory of the medical device server or other backoffice components. Optional additional steps involved in the system 5700can include comparing the final parameter value received in the finalparameter receipt module 5708 with a hard limit or soft limit stored inthe medical device server. If the final parameter value exceeds thelimit, the system 5700 may trigger an alarm in the medical deviceserver, and optionally communicate that alarm back to the medicalinfusion pump via a package deployment or other message. In a furtherembodiment, the alarm is communicated to a medical caregiver associatedwith the medical device.

Operational flow terminates at an end operation 5712, which correspondsto completion of the change in pump parameter values and storage of theupdated pump parameter values in the medical device server or other backoffice component.

FIG. 58 shows a medical device history report 5800 listing original,updated, and final operational parameter values for a medical deviceaccording to the methods and systems of FIG. 57. The medical devicehistory report 5800 includes a medical device label 5802, date and timeinformation 5804, class information 5806, trigger information 5808,message information 5810, location information 5812, and druginformation 5814. The medical device label 5802 corresponds to themedical device name for the device whose history is displayed in thereport 5800. The date and time information 5804 correspond to the timethe various events occurred that are included in the medical devicehistory report. The class information 5806 describes the type andseverity of the event. In the case of a therapy change event, the classinformation 5806 also includes an original value of the changedparameter, the changed value of that parameter, representing the valueentered by a user, and a final value of the parameter, indicating thefinal set value used by the medical device.

The trigger information 5808 displays the trigger associated with themedical device event. In the example shown, an event in an alarmclassification has a high level of concern, and includes a warning inthe trigger information 5808. However, an event describing a therapychange will not activate the trigger information 5808.

The message information 5810 includes information about the status ofthe medical device, such as battery life, therapy delivery progress,therapy parameter limits, or physical characteristics of the device. Thelocation information 5812 includes information related to the locationof the medical device, such as the department, the facility, and theentity controlling the medical device. The drugs information 5814includes information about the drug or therapy being delivered by themedical device, and optionally is only included in the information for atherapy change. Additional information about the medical device can bedisplayed in the medical device history report 5800, based on theinformation tracked by the medical device server and operations webservice.

FIG. 59 shows a therapy history report 5900. The therapy history report5900 displays the same information as is displayed in the medical deviceevent history report 5800 of FIG. 58, but will only display therapyevent information. The therapy history report 5900 includes a medicaldevice label 5902, date and time information 5904, class information5906, trigger information 5908, message information 5910, locationinformation 5912, and drug information 5914, each of which operateanalogously to the corresponding entries in the medical device eventhistory report 5800.

FIG. 60 shows a therapy trending report 6000. The therapy trendingreport 6000 displays a chart of therapy related events over time. In theembodiment shown, the therapy trending report 6000 displays a bar chartshowing the frequency of therapy events by month. Other configurationsdisplaying trends in therapy events are possible as well.

FIG. 61 shows a therapy change history report 6100. The therapy changehistory report 6100 also displays the same information as is displayedin the medical device event history report 5800 of FIG. 58, but onlydisplays therapy change event information. Therapy change eventscorrespond to changed parameters in delivering a therapy using a medicaldevice. The therapy change history report 6100 includes a medical devicelabel 6102, date and time information 6104, class information 6106,trigger information 6108, message information 6110, location information6112, and drug information 6114, each of which operate analogously tothe corresponding entries in the medical device event history report5800 and the therapy history report 5900.

FIG. 62 shows a therapy change trending report 6200. The therapy changetrending report 6200 displays a chart of therapy change events overtime. In the embodiment shown, the therapy change trending report 6200displays a bar chart showing the frequency of therapy change events bymonth. Other configurations displaying trends in therapy change eventsare possible as well.

C. Event Web Service: On-Line Status and Viewing of Device Activity

Referring now to FIGS. 63-66, various features of the event web serviceof FIG. 36 are described. The event web service provides a method bywhich external applications collect event data from the medical deviceserver and back office components. In particular, the event web serviceprovides an indication of the on-line status of the medical device, andalso provides user access to telemetry streams allowing near-real-timetelemetry information regarding operation of a medical device in thecontext of a medical device network as described in FIGS. 1 and 3-4.

FIG. 63 is a flowchart of methods and systems for determining theon-line status of a medical device. The system 6300 executes on amedical device server or other back office components, and expectscommunication from a medical device within a predetermined period inorder to ensure accurate communication between the device and server.

Operational flow within the system 6300 commences at a start operation6302, which corresponds to initial communication between a medicaldevice and a medical device server. Operational flow proceeds from thestart operation 6302 to an expectation module 6304. The expectationmodule 6304 sets in the medical device server and/or back officecomponents an expected, predetermined period within which the medicaldevice server will expect communication.

A receive data operation 6306 determines whether a message has beenreceived by the medical device server. If data has been received by themedical device server, operational flow branches “yes” to an updatemodule 6308, which updates the status of the medical device to indicatethat the device is on-line.

An optional output update module 6310 updates data output from themedical device server based on information received in the message. Theinformation received in the message can include medical device statusinformation, event log data, telemetry data, or various other types ofdata. In one embodiment, the message indicates the beginning of atelemetry stream, and, in response to the message from the medicaldevice, the medical device server and back office components update theappearance of a dashboard screen to reflect the received telemetry data.In a further embodiment, the output update module updates medical devicestatus information in one or more of the back office components.

Operational flow proceeds through the receive data operation 6306, theupdate module 6308, and the output update module 6310 so long as themedical device continues in operation and the receive data operation6306 determines that the medical device server continues to sendmessages to the medical device within the predetermined period.

If the receive data operation 6306 fails to receive data within thepredetermined period, the operational flow branches “no” to an offlinemodule 6312, which changes the state of the medical device to offline inthe medical device server and/or back office components. Operationalflow proceeds to the optional output update module 6310, which updatesthe output to indicate that the currently displayed data is no longerconsidered current by the medical device server until additionalmessages have been received. Operational flow terminates at an endmodule 6314, corresponding to suspension of operation of the medicaldevice network.

FIGS. 64-66 provide methods and systems for operation of telemetrystreams received from a medical device. The telemetry streams describedherein provide nearly-continuous communication from the medical devicesto the medical device server, and are viewable on a dashboard or otherweb portal.

FIG. 64 shows a flowchart of systems and methods for near-real-timedisplay of telemetry information from a medical device. Operational flowin the system 6400 commences at a start node 6402, which corresponds toinitial operation of a medical device capable of transmitting atelemetry stream in a medical device network. A new state 6404 indicatesthat the telemetry stream has not previously been running. After the newstate, a stream startup process attempts to start the telemetry stream,as shown in FIG. 65, below. If the stream startup process fails,operational flow proceeds to a failed state 6406, corresponding tofailure to start the telemetry stream. Operational flow then proceeds toan end node 6408.

If the stream startup process successfully starts, operational flowproceeds to a collecting state 6410, which corresponds to the medicaldevice server collecting telemetry data from the medical device. In thecollecting state, the telemetry data can be stored in the medical deviceserver or other back office components, and also can be output to adashboard or other monitoring user interface.

From the collecting state 6410, a number of possible options affectoperational flow of the system 6400. If a message, including a telemetrystream message, is not sent from the medical device to the medicaldevice server within an expected, predetermined time set in the medicaldevice server or back office components, operational flow proceeds to anoffline state 6412. The offline state 6412 corresponds to the system nolonger regularly receiving telemetry data. If a telemetry report islater received, the system 6400 returns to the collecting state 6410.

If the telemetry stream is paused by a user, operational flow proceedsto a paused state 6414, corresponding to a system which only temporarilyis not receiving telemetry data. The user can resume the telemetrystream to return the system 6400 to the collecting state.

A terminated state 6416 can be reached from the collecting state 6410,the offline state 6412, or the paused state 6414 by the user terminatingthe stream or the system otherwise receiving a medical device power offevent. The terminated state 6414 corresponds to ending the telemetrystream. In the terminated state, the system no longer receivesinformation from the medical device, and the dashboard is not updated.In a possible embodiment, when the system 6400 is in the terminatedstate, a dashboard or other monitoring interface indicates to a userthat data is not currently being collected. From the terminated state,operational flow proceeds to the end node 6408.

FIG. 65 displays exemplary telemetry stream message sequences 6500,6520, 6540, and 6560 performed among: a dashboard 6502, such as the oneshown in FIG. 67; an event tracking web service 6504, such as the oneshown in FIG. 36; a medical device server 6506, as disclosed above inFIGS. 3-4; and a medical device 6508, such as shown in FIG. 2. A firsttelemetry stream message sequence 6500 illustrates a request to initiatea telemetry stream from a medical device to a dashboard. The messagesequence 6500 starts by the dashboard 6502 sending a start telemetrystream message 6510 to the event tracking web service 6504. The eventtracking web service communicates the message 6510 to the medical deviceserver 6506, which in turn communicates the message 6510 to the medicaldevice 6508. The medical device generates a response message 6512indicating success or failure of the message. The response message isrelated back to the dashboard 6502 by the medical device server 6506 andevent tracking web service 6504.

A second telemetry stream message sequence 6520 illustrates initiationof a telemetry stream by a medical device 6508. The medical device 6508generates a telemetry event 6522, which includes near-continualcommunication of telemetry data from the medical device 6508 to themedical device server 6506, which relays the telemetry data to thedashboard 6502 via the event tracking web service 6504. The dashboard6502 displays the telemetry data to the user in a near-real-timefashion. In one embodiment, the dashboard recreates the appearance ofthe medical device. The dashboard transmits a response message 6524 tothe event tracking web service 6504, indicating successful receipt ofthe telemetry stream.

The dashboard 6502 generates a get telemetry window message 6526 andtransmits the message to the event tracking web service, which respondswith a message 6528 indicating success or failure of the command. Thetelemetry window is started at this point, and the dashboard or webportal will display telemetry data.

At this point, if the medical device is powered off, the event trackingweb service 6504 will respond with a fail message and will terminate thetelemetry stream.

A third telemetry stream message sequence 6540 illustrates ending atelemetry stream by shutting off the medical device generating thetelemetry stream. The medical device 6508 generates a power off eventmessage 6542 and sends the message to the medical device server 6506.The medical device server sends a terminate telemetry stream message tothe event tracking web service 6504. The event tracking web service 6504generates a response message 6544 indicating success or failure ofreceipt of the message 6542. The medical device server 6506 relays theresponse message 6544 to the medical device 6508.

A fourth telemetry stream message sequence 6560 relates to the sequence6540 and illustrates ending a telemetry stream by discontinuing thetelemetry stream at the dashboard 6502. The dashboard 6502 generates aterminate telemetry stream message 6562, which is communicated from thedashboard to the event tracking web service 6504, and in turn throughthe medical device server 6506 to the medical device 6508. The medicaldevice 6508 terminates its telemetry stream and generates a responsemessage 6564 indicating success or failure of receipt of the message6562. The medical device server relays the message 6564 through theevent tracking web service 6504 to the dashboard 6502. Additionalmessaging processes are possible in order to start and terminatetelemetry streams using medical devices and dashboards according to thepresent disclosure.

FIG. 66 shows an exemplary class structure defining a telemetry streamclass 6600. The telemetry stream structure 6600 illustrates a portion ofthe functionality of the event web service module 3606. The telemetrystream relates back to and uses a variety of functions from theadministrative web service 3700 of FIG. 37.

The telemetry stream structure 6600 includes a telemetry stream class6602 and a latest event class 6604. The telemetry stream class 6602includes a variety of telemetry-related operations, including starting,terminating, pausing, and retrieving available telemetry streams.Additional telemetry stream operations can be included in the telemetrystream class 6602 as well. The latest event class 6604 includesfunctions for retrieving the latest events, so as to determine when themost recent event was received from the medical device and therebydetermine the on-line status of the medical device, so as to determinethe availability of telemetry stream data. Additional functions can beincluded in the latest event class 6604, and additional classes can beadded to the telemetry stream structure 6600.

Various exemplary dashboards may be used to view telemetry data at aworkstation of other computing device. One example dashboard is shown inFIG. 67. The dashboard 6700 displays telemetry data (e.g. current ornear-current operational status) relating to the pumps with which it isassociated. The dashboard 6700 can be any of a number of dashboardapplications configured to receive and display telemetry data to a userin a near-real-time manner, and can correspond, for example, to thedashboards logically illustrated as dashboard 328 of FIGS. 3-4. Thedashboard 6700 can be updated by a telemetry stream, such as describedabove in FIGS. 64-66.

In the embodiment shown, the dashboard 6700 tracks a name 6702,identifier 6704, domain 6706, address 6708, port 6710, and activityhistory 6712, with respect to each medical device associated with thedashboard. The name 6702 corresponds to a name of a device recognizableto a user, assigned by either the device itself or the server. Theidentifier 6704 provides a unique identification useable by the serverto verify the identity of the medical device. In various embodiments,the identifier can correspond to a globally-unique identifier (GUID),hardware address, or other identification of the medical device. Thedomain 6706 indicates the name of a network in which the medical deviceresides. The address 6708 provides connection information regarding howto communicate with the medical device from the server. In theembodiment shown, the address 6708 is shown as an IP address of themedical device. The port 6710 lists the inbound communication port forthe medical device. The activity history field 6712 lists a date andtime of the last event occurring on the medical device and communicatedto the server.

The dashboard 6700 graphically illustrates an operational status of thepumps with which it is associated. In the embodiment shown, five medicaldevices are tracked in the dashboard 6700, named “MD0333”, “MD0444”,“MD0524”, “MD0324”, and “MD0988.” The first, fourth, and fifth devices(MD0333, MD0324, and MD0988) are illustrated as powered and delivering atherapy to a patient. The second device (MD0444) is shown to be in analarm state, indicating a possible abnormal operation of the device oremergency condition related to the patient associated with that device.The third device (MD0524) is illustrated to be in a fault state,indicating a malfunction or error occurring in that medical device.Other states illustrating an operational status may be illustrated onthe dashboard 6700 as well.

Optionally, additional features can be included in the dashboard 6700that allow a user to filter or display different types of information.In the embodiment shown, a pause check box 6714 and an offline devicescheck box 6716 allow a user to selectably modify the dashboard. Thepause check box 6714, when selected, causes the dashboard to “freeze”temporarily halting the updating of information in the dashboard toallow a user to view the state of the dashboard at a single time. Whenthe pause check box 6714 is unselected, the status information on thedashboard can continually update as data is received from the associatedmedical devices. The offline devices check box 6716 enables thedashboard to display information related to devices associated with thedashboard, but which are not online and from which the dashboard has notreceived recent status information. Other display features and filterscan be incorporated into the dashboard as well, allowing a user toselect the desired set of devices to monitor and allowing the user toview a specific portion of the telemetry data received from those users.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the invention.Those skilled in the art will readily recognize various modificationsand changes that may be made to the present invention without followingthe example embodiments and applications illustrated and describedherein, and without departing from the true spirit and scope of thepresent invention, which is set forth in the following claims.

1. A method of communication between a medical device and a server, themethod comprising: associating metadata with one or more medicaldevices, the metadata corresponding to an attribute of the medicaldevices; and storing the metadata on a server, the server configured tocommunicate with each of the medical devices by using the metadata. 2.The method of claim 1, wherein the metadata corresponds to an attributecommon to all of the medical devices.
 3. The method of claim 1, furthercomprising: associating second metadata with a second medical device,different from the one or more medical devices; and storing the secondmetadata on the server, the server configured to communicate with eachof the medical devices and the second medical device by using at leastone of the metadata and the second metadata.
 4. The method of claim 1,wherein the one or more medical devices include medical devices from twoor more medical device manufacturers.
 5. The method of claim 1, furthercomprising associating second metadata with at least one medical deviceof the plurality of medical devices, the second metadata correspondingto at least one custom attribute of the medical device.
 6. The method ofclaim 5, wherein the metadata and the second metadata definecapabilities of the medical device.
 7. The method of claim 5, whereinstoring the metadata on a server further comprises storing the secondmetadata on the server.
 8. The method of claim 1, wherein the metadataincludes a medical device identifier.
 9. The method of claim 1, whereinthe metadata includes a medical capabilities variable.
 10. The method ofclaim 1, wherein the metadata includes a name of the medical device. 11.The method of claim 1, wherein the metadata corresponds to an attributeof the medical devices, the attribute selected from the group consistingof: patient information; user information; control information; druginformation; and location information.
 12. The method of claim 1,wherein the metadata corresponds to an event that is tracked by themedical device, the event selected from the group consisting of: powerevents; alarm events; fault events; maintenance events; telemetryevents; therapy events; therapy change events; and custom events. 13.The method of claim 1, wherein the second metadata includes an attributeof a medical infusion pump.
 14. The method of claim 1, furthercomprising, on the server, selecting a medical device using themetadata.
 15. The method of claim 14, further comprising sending amessage to the medical device, the message including metadata.
 16. Themethod of claim 1, wherein the metadata is structured using XML.
 17. Themethod of claim 1, further comprising using the metadata to distinguishamong the plurality of medical devices.
 18. A system for communicatingwith a plurality of medical devices, the system comprising: a pluralityof medical devices; a server communicatively connected to the pluralityof medical devices, the server comprising: a memory configured to storemetadata describing the medical devices; a programmable circuitoperatively connected to the memory, the programmable circuit configuredto execute program instructions to: associate metadata with one or moremedical devices, the metadata corresponding to at least one attribute ofthe medical devices; store the metadata on a server; and communicateinformation including the metadata with at least one of the medicaldevices.
 19. The system of claim 18, wherein the metadata corresponds toan attribute common to all of the medical devices.
 20. The system ofclaim 18, wherein the plurality of medical devices include medicaldevices from two or more medical device manufacturers.
 21. The system ofclaim 18, wherein the programmable circuit further contains programinstructions to associate second metadata with at least one medicaldevice of the medical devices, the second metadata corresponding to atleast one custom attribute of the medical device.
 22. The system ofclaim 21, wherein the metadata and the second metadata definecapabilities of the medical device.
 23. The system of claim 22, whereinthe programmable circuit is further programmed to store the secondmetadata on the server.
 24. The system of claim 23, wherein the firstmetadata includes a medical device identifier.
 25. The system of claim18, wherein at least one of the medical devices is a medical infusionpump.
 26. The system of claim 25, wherein the second metadata includesan attribute of the medical infusion pump.
 27. The system of claim 18,wherein the metadata corresponds to an attribute of medical deviceselected from the group consisting of: patient information; userinformation; control information; drug information; and locationinformation.
 28. The system of claim 18, wherein the metadatacorresponds to an event that is tracked by the medical device, the eventselected from the group consisting of: power events; alarm events; faultevents; maintenance events; telemetry events; therapy events; therapychange events; and custom events.
 29. A method of communication betweena medical device and a server, the method comprising: associatingmetadata with each of a plurality of medical devices, the metadatacorresponding to at least one attribute common to the medical devices;associating second metadata with at least one medical device of theplurality of medical devices, the second metadata corresponding to atleast one custom attribute of the medical device; storing the metadataon a server, the server configured to communicate with each of themedical devices by using the metadata; selecting a medical device; andcommunicating information including the metadata with the medicaldevice.
 30. A method of communication between a plurality medicaldevices and a server, the method comprising: generating a message to amedical device server at a medical device, the message includingmetadata used to identify the medical device; and receiving a messagefrom the medical device server at the medical device, the messageincluding metadata identifying the medical device.
 31. The method ofclaim 30, wherein the plurality of medical devices include medicaldevices from two or more medical device manufacturers.
 32. The method ofclaim 30, further comprising: associating second metadata with a secondmedical device, different from the plurality of medical devices; andstoring the second metadata on the server, the server configured tocommunicate with each of the medical devices and the second medicaldevice by using the metadata and the second metadata.